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Sources and Resources for All C Programme 


Volume 3 Number 1 


From Prentice-Hall & Catalytix 


An Interactive 
‘C’ Tutorial 


What Others Say 


‘“... unqualified recommendation.”’ 
].P., Tennessee 
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..a better learning environment than ever.”’ 
Data Training Magazine, April 1986 
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...an excellent alternative to live instructors.’’ 
Walter Zintz, Editor-at-Large, UNIX / World 
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Interactive 
The Interpreter gives you fine control over the execu 
Two Integrated Parts tion and debugging of a C program or fragment. A 


program can be stopped at any point and the values 
of active variables can be inspected and changed. 
Program modifications are effective immediately with- 
out waiting for compiling, assembling and link edit- 
ing. Function calls, statements, and expressions can 


: be traced tel ther. 
z. tne © Irainer Jutorial Textbook. e traced separately or togetner 


1. A powerful C Interpreter for designing, 
debugging, and executing your programs; 
plus an On-Line Library of complete C 
programs. 


Comprehensive Affordable & Widely Available 


: 1. The Interpreter runs on a variety of systems; here 
The C Trainer, written by Alan Feuer, takes you 


are a few: 
through the development of a collection of C pro- q 9 ‘ 
grams. The programs range from introductory to Macintosh and IBM PC/XT/AT (DOS) — | 
advanced; they illustrate the features of C using mod- oun 2 or 3—-$195 
ern programming practices. Included with the Tuto- oh ry MicroVAX (UNIX or VMS)—$195 
rial are chapters that examine in depth various aspects <y ow Pyramid and Gould —$595 
of C, such as expressions, declarations, initializations, AS \ Al&! 3B/2-$145 38/5—5195 
arrays and pointers, and macros. so” ee VAX/780 (UNIX or VMS)—$395 
(> > 2. The C Trainer Tutorial Book — $22.95 
The C Trainer programs perform useful tasks which XS _ _ 
_ illustrate a variety of important algorithms. 3. Shipping Charges — $5.00 (within U.S.) 
_ Advanced topics include: 
© co-routines ¢ recursive descent parsers 
- binary trees «finite state automata Production Quality Software Tools 
_———C* ispatch tables «semantic networks For UNIX and VMS 
___-sindirect pointers — * tail-recursion elimination 
_ Save time and help automate software: 
- ¢ Design ¢ Integration 
_ To Order C Trainer Write or Call: : ° Pies ee 
* = enan 
_ Catalytix Corporation alae = 


_ 55 Wheeler Street 
_ Cambridge, MA 02138 
(617) 497-2160 


— Call (617) 497-2160 for complete details 
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PAINLESS WINDOWS. 


Windows. Data Entry. Menus. 
Finally, a C programmers’ tool that makes 
them as easy to use as printf). 

With Greenleaf DataWindows”, 


you move in quantum leaps! 


GEE Snazzy Window Treatments 


DataWindows represents an important 
breakthrough in C programming tools. It 
sets you free so you can create exciting 
programs quickly and easily, saving both 
time and money! Developed to work with 
the IBM PC, XT, AT, compatibles, and 
MSDOS or PCDOS, DataWindows is a 
carefully tooled system of C functions which 
will jazz up your programs with 
unprecedented efficiency. 


Greenleaf DataWindows is integrated 
windows, transaction data entry, pop-up, 
pull-down, and Lotus style menu systems 
with: 
@ Screen Management. You don’t have to 
remember what’s on the display or the 
sequence in which you put it there. 
DataWindows does the grunt work. 
There are no restrictions. 


@ Transaction Data Entry. Data entry 
windows can have any number of fields 
with sophisticated options for reading 
many data types. Calls are made to help, 
validation, and other functions. Full 
featured text editing, protected and 
mandatory fields, dBASE type picture 
strings, context sensitive help, validation 
of fields and transactions, redefinable 
keys, password entry, attribute control, 
keyboard idle and much more. 


@ Device Independence. It detects the type 
of display adapter your computer is using 
and adjusts to it automatically for CGA, 
EGA, or monochrome. Logical video 
attributes are easy to use for color or 
monochrome. 


= Compatibility, Runs with Microsoft 
Windows and IBM TopView. 


= The Greenleaf Tradition of Quality. Reliable 
products. Professional documentation that 
gets you up and running quickly and 
keeps you there. Reference card. 
Newsletter and Bulletin board. 


IBM, Microsoft & dBase, are registered trademarks of International 
Business Machines, Microsoft Corporation & Ashton-Tate respectively. 
PCDOS, IBM PC, XT, AT, & TopView are trademarks of IBM; MSDOS 
and Microsoft Windows are trademarks of Microsoft Corporation. 


Stop Window Shopping 
Order Today. Or call toll free for a free 


demo of the windows library that makes 
all the others obsolete. 


Order any of these high performance 
tools by calling your dealer or 
1-800-523-9830 today. Specify compiler 
when ordering. Add $8 for UPS second 
day air, or $5 for ground. Texas residents 
add sales tax. MasterCard, VISA, P.O., 
check, COD. In stock, shipped next day. 


Greenleaf DataWindows $225 
DataWindows Source Module $225 
The Greenleaf Comm Library v2.0 $185 
The Greenleaf Functions v3.0 $185 
Digiboard Comm/4-II $325 
Digiboard Comm/8-II $535 


GRREEWNIEAF 
S | ee 
1411 LeMay Drive, Suite 101 
Carrollton, TX 75007 
Call Toll Free 
1-800-523-9830 
In Texas and Alaska, call 


214-446-8641 
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BES Window Dressings aaa 


@ Simple or Complex Windows. Up to 254 
powerful overlaid windows 
simultaneously, all with jist-one kind of 
window to remember! Yet any window 
can be from one character to 32K! 


@ Easy Window Operations. DataWindows 
lets you move, zoom, frame, title, change 
colors, titles, frames, size, location, and 
make windows visible or invisible at will! 
Functions set cursor, attributes, and write 
data to any window or “current window”. 
Word wrap, auto scroll, keyboard 
functions. 


@ Write to Any Window Any Time. Windows 
may be visible, overlaid, or invisible, and 
you can write to them anyway. What you 
write will be seen when the windows 
become visible. 

@ DataWindows is fast! It writes directly to 
video memory (in some modes). 


@ Easy to save! Any window, complete with 
attributes, can be saved on disk quickly 
and efficiently. 


® Source code available. No royalties. 
HEE Also from Greenleaf: a 


The Greenleaf Functions v3.0 
The most complete, mature C language 
function library for the IBM PC, XT, AT 
and close compatibles. Includes over 225 
functions — DOS, disk, video, color text 
and graphics, string, time/date, keyboard, 
disk status and Ctrl-Break functions plus 
many more. 


The Greenleaf Comm Library 
Our 2.0 version is the hottest 
communications facility of its kind. Over 
120 functions — ring buffered, interrupt 
driven asynchronous communications for 
up to 16 ports simultaneously with 
XMODEM, XON/XOFF, many many 
sophisticated features. 


We support all popular C compilers for 
MSDOS/PCDOS: Microsoft, Lattice, 
Computer Innovations, Aztec, DeSmet, 
and others. 
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W hen large and complex software programs and systems 


are being developed on personal computers, effective 
management of the revisions and versions becomes critical. 
The POLYTRON Version Control System (PVCS) sim- 
plifies this process and lets you effectively control the pro- 
liferation of code changes. We used UNIX SCCS and RCS 
as models. However, our own experience, and the input 
of hundreds of PC programmers has enabled us to 
significantly improve upon these models. 


PVCS provides many powerful functions including: 
* Storage & Retrieval of multiple revisions of text. 
* Maintenance of a complete history of changes. 


* Maintenance of separate lines of development 
using branching. 


* Resolution of access conflicts. 
* Merging of simultaneous changes. 


* Modules can be retrieved by their own revision 
number, system version number, or specified date. 


* Efficient disk storage. PVCS uses a very intelligent 
difference detection technique that minimizes the 
amount of disk space required to store a new 
version. 


PVCS Maintains System Integrity 


PVCS prevents system corruption that could ordinarily 
result from security breaks, user carelessness or malfunc- 
tions. The levels of security can be tailored to meet the 
needs of your project. 


POLY TRO 


PVCS 


THE MOST POWERFUL AND 
FLEXIBLE SOURCE CODE 
REVISION & VERSION CONTROL 
SYSTEM FOR PCS AND 

LOCAL AREA NETWORKS 


PROGRAMMERS, PROGRAMMING. TEAMS, 
PROJECT MANAGERS, LIBRARIANS AND 
SYSTEM ADMINISTRATORS FIND 

PVCS. INDISPENSABLE 


The Preferred Version Control System 


PVCS is now being used in personal computer software 
development environments at hundreds of high-technology 
corporations including: 


Hewlett-Packard 3 Com 
GIE Data Services IBM 
Sperry ‘Texas Instruments 


Westinghouse Electronics 
Nestar Systems 


ROLM Corp. 


Maintains Source Code Written In ANY 


Requires DOS 2.0 or higher. Compatible with the IBM PC, 
XT, AT and other MS-DOS PCs. 


Only PVCS meets the needs of Independent Programmers and Corporations. Once 
you standardize on PVCS, the “Logfiles” used to track and monitor changes are 
interchangable between any PVCS product. You will receive full credit for your 


initial purchase if you upgrade to a higher-priced PVCS. 

Personal PVCS — offers most of the power and flex- 

ibility of the Corporate PVCS, but excludes the features necessary l Q 
for multiple-programmer projects. 

Corporate PVCS — Offers additional features to maintain source code 
of very large and complex projects that may involve multiple programmers. Includes 
“Branching” to effectively maintain code when programs evolve 

on multiple paths (e.g., new versions for different systems, or a 395 
new program based on an existing program). Single user. 

Network PVCS — Extends Corporate PVCS for use on Networks. File 
locking and security levels can be tailored for each project. 

5-Station License $1,000. Call (503) 645-1150 for pricing on 1000 


Licenses for more than 5 Stations. 


TO ORDER: VISA/MC 1-800-547-4000. Dept. No. 358. 
Oregon and outside US call (503) 684-3000. Send Checks, 
PO.s to: POLYTRON Corporation, 1815 NW 169th Place, 
Suite 2110, Dept. 358, Beaverton, OR 97006. 


High Quality Software Since 1982 _ ° 
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/* Editors Comment */ 


Well that ‘‘dreaded’’ moment 
has arrived (and gone, in fact) — 
the four-month ANSI C _ Public 
Review Period, that is. For quite 
some time I wondered whether the 
Standard contained too much inven- 
tion and change and I looked for- 
ward to hearing from the public. 
Would they give it the thumbs 
down, would they appreciate and 
understand the compromises that 
went into it, would they in fact 
even know about the draft standard 
or that the review period existed, 
and if so, would they care? 


Some of these questions have 
been answered. Apparently quite a 
few C folks know about the stan- 
dard judging by the amount of net- 
work traffic about that topic. There 
have been quite a lot of negative 
comments including, of course, the 
all too familiar “‘If it isn’t broken, 
don’t fix it’’. But as far as the com- 
mittee is concerned, the comments 
of immediate interest are those 
received by ANSI as formal public 
comments. Apart from being 
interested in this feedback the com- 
mittee is obliged to formally 
respond to each and every such 
comment, and the reply cannot be 
simply ‘“‘Thanks for sharing that 
with us.’’ 


Although there were probably 
less than 20 formal comments 
received, the total number of issues 
raised in those letters approached 
something like 300 to 400, a non- 
trivial amount. And this was on top 
of the informal public comments 
received over the last year that the 
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committee had previously elected to 
handle in a like manner. Conse- 
quently, much of the Boulder meet- 
ing was taken up with “‘comment 
processing’’ as will be a good part 
of the Paris meeting in June. 


The original schedule called for 
a revised standard to be voted out 
in Paris but that now seems impos- 
sible. Therefore, the next formal 
comment period (this time of two 
months only) should begin about 
the middle of October 1987, having 
been voted out at the September 
meeting. This has caused _ the 
December meeting agenda to be 
pushed back to late January 1988 at 
which time it is hoped to vote out 
the final standard. If at that meeting 
we do not handle public replies to 
the publics’ satisfaction or we make 
any substantial change to the docu- 
ment, we are obliged to go ‘round 
again for another two month 
review. This would delay the stan- 
dard by another 3-6 months. And 
while I don’t wish to sound pes- 
simistic, my guess is that we will 
have that second two-month review. 
I hope not, but the longer we are 


Acknowledgements 


Out there the more comments we 
will attract and we’ll have to go 
over a lot of old ground by discuss- 
ing issues that many of us thought 
we put to rest several years ago. 


While many of the committee 
members would probably love to 
quit all this travelling, reading, and 
arguing, etc. the standard we vote 
Out will be what we all have to live 
with for the next 10 years or so, so 
we may as well take a few extra 
months to get it nght. Your pati- 
ence will help as will your reports 
of the ANSI additions already 
available in your favorite compiler. 


You are at liberty to write to the 
committee if you like but as an 
alternative, particularly if you 
haven’t been tracking the standard 
Closely or for a long period, write 
to me. I will endeavor to answer 
questions as appropriate and to 
bring any new or substantive issues 
before the committee on your 
behalf. 


— Rex Jaeschke 
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Doctor C and Doctor C’s Pointers are trademarks of Rex Jaeschke. 
The C Journal is a trademark of InfoPro Systems 


MS-DOS is a trademark of Microsoft. 


POSIX is a trademark of IEEE. 


UNIX is a registered trademark of AT&T. 
PDP and DEC are registered trademarks of Digital Equipment Corp. 


NEW! FROM 
BLAISE 
COMPUTING 


Today’s programmers 
need more than yes- 
terday’s tools. Re- 
quirements such as 
removable windows 
and ‘‘sidekickable”’ 
pop-up utilities 
are changing 
the face of pro- 
gram design. 
You need to fil- 
ter interrupts so 
that other resi- 
dent programs 
still work. You 
need the ability to switch between 
multiple display pages and monitors. 
Today’s technical demands are almost 
endless, but C TOOLS PLUS gives you 
what you need. 


SOLID LIBRARY SUPPORT 


Blaise Computing offers you solid li- 
brary support that can meet all your 
demands and more. C TOOLS PLUS 
embodies the full spectrum of general- 
purpose utility functions that are criti- 
cal to today’s applications. 


Here’s just part of the PLUS 
in C TOOLS PLUS: 

@ C TOOLS and C TOOLS 2 compatibil- 
ity —two packages that receive rave 
reviews for quality, organization, usa- 
bility and documentation. 


@ FULL SOURCE CODE 


With “C” 


@ WINDOWS that are stackable, re- 
movable, that support word wrap and 
that can accept user input. 


@ INTERRUPT SERVICE ROUTINE 
support for truly flexible, robust and 
polite resident applications. 

@ MULTIPLE monitor and display 
support, including EGA 43-line mode. 

@ FAST DIRECT VIDEO ACCESS for 
efficiency that will not constrain good 
program design. 

@ DOCUMENTATION, TECHNICAL 
SUPPORT and attention 
to detail that have distin- 
guished Blaise Computing 
products over the years. 


C TOOLS PLUS supports 
the Microsoft (and IBM) 
3.00 and Lattice 3.00 C 


compilers and 1s just 
$175.00. 
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™ Also Available Are: 
C VIEW MANAGER — 
A kit for building data 
entry screens and menus. 


For The Programmer 


Whose Alphabet 
Begins & Ends 


Begin by designing on- 
screen what the operator 
will see; call upon our 
library functions from 
your program to display 
the screens and retrieve 
the data. Just $275, in- 
cluding all library 
source code. 

C ASYNCH MAN- 
AGER — provides 
the crucial core 
of hardware in- 
terrupt support 
needed to build 
applications that 
communicate. It 
also includes the “KMODEM” file-transfer 
protocol and support for Hayes-compatible 
modems. All source code is included for $175. 
C TOOLS & C TOOLS 2— an indispensable 
combination still available at a low price of 
$175, including all source code. See re- 
view in PC Tech y IN Journal, 6/85. 


SIRS SUR IAes cn,  Acceeendar BES Ce 
BLAISE COMPUTING INC. 


2560 Ninth Street, Suite 316 Berkeley, CA 94710 (415) 540-5441 


ORDER TOLL-FREE 800-227-8087! 


CA residents call (415) 540-5441 


—_ 


e THE C JOURNAL 


The C Journal 


Ror eas ne Rex Jaeschke 
Publishetaets 3 uations David Fiedler 
Associate Publisher ................. Susan Fiedler 
Factotutil 2ncccciiicnccs wes. Robin Caldwell 
Contributing Editor................ Thomas Plum 


The C Journal (SSN 8756-9736) is pub- 
lished quarterly by InfoPro Systems, PO 
Box 220, Rescue, CA 95672. Telephone 
(916) 677-5870, TLX = 151296379 
INFOPRO. 


UUCP {ames,attmail hplabs, pyramid ucdavis} !infopro!cj 


Entire contents Copyright © 1987 InfoPro 
Systems. No portion of this publication 
may be reproduced, stored, or transmitted 
in any form, including computer retrieval, 
without written permission from the pub- 
lisher. All Rights Reserved. Printed in the 
United States of America. Quantity reprints 
of selected articles may be ordered. Signed 
articles express the opinion of the author 
and are not necessarily the opinion of the 
publisher. 


Editorial: Please address press releases, 
letters to the editor, manuscripts, and soft- 
ware for review to: Rex Jaeschke, Editor, 
The C Journal Suite 101, 1810 Michael 
Faraday Drive, Reston, VA 22090. Phone 
(703) 860-0091. 


Subscriptions: you should still send all 
payments or inquiries to InfoPro Systems, 
PO Box 849, Denville, NJ 07834. Phone 
(916) 677-5870. Subscriptions to The C 
Journal cost $28 per year (add $12 per 
year for overseas airmail). Purchase orders 
are accepted from rated firms. Checks 
should be made payable to InfoPro Sys- 
tems, and should be in U.S. funds, drawn 
on a U.S. bank. 


Advertising: For rate cards or other infor- 
mation on placing advertising in The C 
Journal, contact our Advertising Depart- 
ment at (916) 677-5870 or write to InfoPro 
Systems, PO Box 220, Rescue, CA 95672. 


Mailing Lists: We occasionally make our 
mailing list available to companies whose 
products we feel might be of interest to our 
readers. If you do not wish to receive such 
mailings please write to InfoPro Systems, 
Mail Preference Dept. CJ, PO Box 849, 
Denville NJ 07834. 


Postmaster: Please address change of 
address notice (Form 3579) to InfoPro Sys- 
tems, Dept. CJ, PO Box 849, Denville, NJ 
07834. 


THE C JOURNAL? 6 


Publisher’s Platform 


Communications Special 
Issue 


There’s a lot more to communi- 
cations than just loading your 
favorite modem driver. We've 
already covered some high-level 
communications libraries, but what 
happens when you have to get 
down closer to the hardware? 
Someone has to figure out how to 
bash bits down the line, and if 
you’re a programmer, that someone 
is probably you. 


This issue, Curtis Wright gives 
us some information on the use of 
CRC (Cyclic Redundancy Code) 
checking and Donald Berryman 
discusses the implementation of 
standard communications protocols 
from C using X.25 as an example. 
Both authors have _ considerable 
experience in C and communica- 
tions. 


Feature Articles 


Once again Matt Bishop from 
NASA Ames writes for us; this 
time on the differences between 
array names and pointers. If you’ve 
ever compiled a program and had to 
re-edit with a few &’sor *’s, this 
article is for you. 


Rob Murray of AT&T contin- 
ues with his series on C++. This 
time he reverts back to his conser- 
vative self after the last episode in 
space shooting down various alien 
craft. Doctor C gives us the inside 


story on a past puzzle, which 
apparently has been causing more 
than a few readers some loss of 
sleep. 


Dennis Deloria continues his 
yacc tutorial series with Part 2, 
and gives us plenty of reading 
material references to get more 
details. Mark Tokay gives us some 
tips on the C/UNIX job market. 


Regular Features 


Just when you thought you had 
mastered C, along comes this 
issue’s puzzle corner. This seem- 
ingly innocent declaration is not 
quite as it first appears. In fact, it 
may change your thinking about the 
kinds of derived types C can be 
used to implement. Even if you do 
solve the puzzle, you might have a 
tougher time coming up with a use 
for the declaration. 


This time we put the 
SPOT_LIGHT on Brian W. Ker- 
nighan, prolific author and member 
of the prestigious Bell Labs Com- 
puting Science Research Center 
Staff. 


Tom Plum gives us his quar- 
terly report on the latest ANSI C 
Standards meeting in Boulder, CO. 
And if that’s not enough, we reprint 
a letter from Dennis M. Ritchie that 
he wrote to the ANSI C Standards 
Committee late in 1986, 


spaghetti 


BASICA 


BAS_C™ | | BAS_PAS™ 


scoped 
indented 


structured 


PASCAL 


Benchmark Test _ pasica Turbo Pascal V.3. Lattice C V3.1 


BAS_C converts Basica to C which can be directly compiled by any C compiler. 

BAS_PAS converts Basica to Turbo Pascal. Both BAS_C and BAS_PAS transform the spaghetti 
code to the structured program automatically, detect the syntax error, and deadcode. 

High conversion ratio. The converted program is scoped, indented, structured, split into 
many modules at the top down fashion. Graphic, random file. Many options. All automatic. 


Basic runtime library (source code, no assembler) is separately available to many compiler at the 


nominal cost. 
Maximum 


Demo 


Sample conversion: send your own Basic program 
(100line/$1) and receive the converted list. 


Shipping & handling $5, oversea $15. No credit card. 
Gotoless Conversion, P.O.Box 50068, Denton, TX 76206 
Phone (214) 221-0383 9:00 AM - 5:00 PM M-F 


$149.00 | $199.00 
$280.00 | $375.00 | Unlimited 


Economy 
Commercial 
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* mailbox 


Dear Editor, 


I would like to point out an 
inaccuracy in your reply to John 
Ridley’s letter in the *mailbox of 
The C Journal Volume 2 Number 
3. You stated: ‘*... on Intel 8088- 
class processors when using 32-bit 
data pointers, that register 
char *pc will be ignored since a 
32-bit pointer cannot be stored in a 
16-bit register.”’ 


This sounded as if it is impossi- 
ble to process 32-bit values in C 
due to some limitation of the 8088. 
In fact, all C compilers must handle 
32-bit quantities when operating on 
long int data objects. The way 
this is done is to use two 16-bit 
registers to contain the 32-bit value. 


The same can be done with 32- 
bit pointers. In fact, many C com- 
pilers will NOT ignore _ the 
register declaration. But 
whether a program will benefit 
from any such register declara- 
tion depends on how the values are 
used and the compiler being used. 
In the classic *p++ = *q++; 
loop, it is probably better to keep 
the two pointers in registers, even if 
they are 32-bits. 


Sincerely, Dan Lau 
Santa Clara, CA 


[Rex: Thanks for the information. ] 


Dear Editor, 


I have found a nice method to 
Switch debug statements on and off. 
The normal way is to surround 
them with #ifdef DEBUG and 
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#endif preprocessor directives. I 


think it is more readable to use a 
construct like 


Tt. paririe .o je /* * / 
where the T at the beginning is 
used to toggle the following 
statement(s) (up to the next com- 
ment) on and off, by replacing T 
with either nothing or with /* as 


follows: 


#ifdef DEBUG 
#define T 
#else 
#define T /\ 


* 


#endif 


To define T as /* we need to 
fool the preprocessor, since it 
detects comments before doing any- 
thing else. To do this, we place the 
asterisk on a _ continuation line. 
Since the preprocessor doesn’t see 
the token /*, everything works as 
expected. 


This definition can be placed at 
the top of your source file or in a 
header. It works fine with C com- 
pilers in UNIX environments. 


Yours Sincerely 
Wilfried Soker 
Frankfurt 

West Germany 


[Rex: It’s an interesting idea but I 
see a problem if you don't have a 
comment in the right place — it 
would be easy to have more State- 
ments than required, treated as a 
comment. A more serious problem, 


at least from my interpretation of 
the proposed ANSI C_ language 
standard draft is that I don’t think 
your technique will work with an 
ANSI-conforming compiler. 


The phases’ of translation 
defined in section 2.1.1.2 indicate 
that continuation lines are handled 
very early on. That is, the trailing 
backslash character is removed 
BEFORE macros are expanded so 
that T will indeed be treated just 
as if you had written #define T 
/* and since comments are 
replaced with a single space, all 
source up to the next close com- 
ment will be ignored, possibly 
including the closing #endif, in 
which case you will get a syntax 
error of some kind. At the very 
least, you will not get the desired 
result. Sorry. 


The phases of translation 
describe the precedence among the 
syntax rules of translation. While 
an implementation is not required 
to exactly mimic this separation 
into separate phases, it is obliged 
to execute these functions in the 
specified order. These phases have 
been carefully specified by the com- 
mittee since this area has seen 
some of the biggest differences 
between implementations. Other 
areas of the UNIX pcc (portable C 
compiler) preprocessor have been 
affected by the proposed standard 
— one area that comes to mind has 
to do with token pasting and macro 
expansion. Some of the tricks 
played here in the past will not 
work in the near future.] 


One possible solution to your 
problem is: 


#ifdef DEBUG 
#define T 
#else 

#define T(a) a 
#endif 


T( print? (2 ../* 
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sO now the statement either expands 
to the null statement or the actual 
statement. Be careful with the null 
Statement though, as it may ter- 
minate a for or while loop 
accidentally if you haven't used a 
compound statement. 


Correction 


[Rex: My reply to Jonathan Rey- 
nolds’ letter re typedef and 
#define in The C_ Journal 
Volume 2 Number 4 contained an 
error as a result of an editor macro 


—% 
N 


ieee aR il PES, “" ~ 
» YS Y 


gone wild. Near the end of my 
reply I stated: ‘’For example, 
typedef char *(*) () 
PFPTRINT; declares PFPTRINT 
to be a function that returns a 
pointer to a function of return type 
char! 


This is incorrect. The correct 
typedef is typedef char 
(*PFPTRINT()) ()>. The 
incorrect type definition is not valid 
at all. In fact, it contains a cast into 
a pointer to a function that returns 
a pointer to char. 


Lb 


Our C Interpreter provides the finest and fastest development environment for C 
and is compatible with your compiler. 


e Fast Semi-Compilation -- We convert source 
to tokens faster than any product (existing or 
announced) on the market. 
Interactive Debugging -- See your code come 
to life as you single step, set breakpoints, call 
functions, view data, execute any C expression. 
Complete Language -- We’ve always 
supported full K&R, now we support the 
usual ANSI enhancements as well (structure 
assignment, enumerations, etc. ) as well as 
keywords cdecl and far. 
e Multiple Modules -- an accurate reproduction 
of a typical multiple module compiler 
environment brought to you in a high speed 
interactive interpreter. 
Multi-file, configurable editor -- features fast 
screens, inter-file copies and moves, etc. etc. 
Spring from file to file, module to module. 
Develop as you never did before. Completely 
reconfigurable. 
Complete Compatibility -- For each supported 
compiler we provided a separate C-terp with 
separate documentation (each compiler is a 
little bit different). We provide a batch file to 
link in your compiler’s entire library. We 
make sure the data alignment, bit field order, 
and pre-processor variables are compatible 
with your compiler. We care about 
compatibility. 
e Shared symbols option -- for those large 
75-module applications. 
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e Software Paging -- for those big jobs. Our new 
and improved paging can now access Extended 
Memory directly. 

e Pointer checking -- An out-of-bounds 
assignment will put you into debug mode with 
the offending statement highlighted. 

e Object module support -- Link in not only your 
compiler’s library but your own libraries (large 
model), assembler routines, and commercial 
libraries such as Essential Graphics, HALO, 
Windows for Data, Greenleaf, Vitamin C, etc. 
Our function pointers are compatible with 
compiled C (a must for using commercial 
libraries) and we support call in (from compiled 
to interpreted) as well. 
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batch mode, dual display and graphics support, 
tracing and 8087/80287 as well. 
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Even so, the origins of the name 
of the type are hardly obvious. This 
is because during editing, I 
somehow got two examples mixed 
up. The type PFPTRINT was sup- 
posed to be an acronym for a 
pointer to a function that returned 
a pointer to an int. And that type 
is declared using typedef int 
* (XPFPTRINT) ();. 1 hope I got 
that straight. I think I did anyway 
— at least that’s what my trusty C- 
to-English-to-C translator program 
tells me.] 


From Our Electronic 
Mailbox 


Dear Editor, 


Your author discusses _ the 
‘‘register’’ storage class in his first 
reply of the month. He claims that 
‘‘register’’ may be used on any data 
type (correctly). 


He then claims that for some 
implementations and for some data 
types, a syntax error may be gen- 
erated for items that won’t go into 
registers. I submit that if his com- 
piler generates an error for ANY 
register declaration within the scopy 
of a function, his compiler is bro- 
ken. 


A compiler should accept the 
‘“register’’ storage class for any 
data type, even if the data type 
clearly won’t go into a register. A 
compiler is not, of course, under 
any obligation to actually put any- 
thing INTO a register unless it feels 
like it. 

I hope that this clears up a little 
confusion. 


Tanner Andrews, Systems 
Compudata South, Deland 
ki4pv!tanner 


P.S. I note that you print the names 
of the authors, and their employers. 
Why don’t you go ahead and go 
whole hog — give us their elec- 
tronic addresses? 


co 


The March 1987 


[Editor's note: To join X3J11, cor- 
tact Dr. Plum at Plum Hall Inc, 1 
Spruce Ave, Cardiff NJ 08232, 
(609) 927-3770. To order the 
public review copy of the proposed 
standard, call Global Engineering 
Documents at 800-854-7179 or call 
the X3 Secretariat at 202-737- 
8888.] 


March Decisions 


At the March meeting, the com- 
mittee addressed suggestions arising 
from the comments received during 
the public review period, which 
ended March 7. Thirty-two public 
comments were received, but some 
were quite detailed and lengthy, so 
several hundred points were 
addressed. Many _ typographic 
corrections were made; requests for 
editorial clarifications were usually 
granted; but most requests for new 
features or “‘inventions’’ were not 
granted, in an attempt to avoid 
‘‘creeping featurism.”’ 


Not all the public comments 
could be addressed at the March 
meeting; some remain to be 
addressed at the June meeting in 


by Thomas Plum 
© 1987, Plum Hall Inc. 
All rights reserved. 


Paris. Here are the March decisions 
of concern to the programming 
public. 


2.2.4.2: The minimum decimal 
digits for a double or long double 
was increased from 6 to 10. 


3.1.1: The language keywords 
(int, while, ...) are not reserved to 
the preprocessor. (The draft was 
previously inconsistent on_ this 
point.) 


4.1.2: The draft had previously 
reserved all identifiers, internal and 
external, that begin with under- 
score, for use by implementer- 
defined ‘‘hidden’’ functions and 
macros. Now, internal names that 
begin with an underscore and a 
lower-case letter are available for 
use by the programmer. — This 
allows, for example, the common 
practice of prefixing ‘‘private’’ 
member names with underscore. 


4.1.4: A new standard header, 
<errno.h>, has been added. The 
declaration of errno was moved 
from <stddef.h> to <errno.h>. 
(However, any other standard 
header whose functions make refer- 


Meeting of X3J11 


ence to errno will also contain a 
declaration of errno.) Freestanding 
environments are now required to 
provide <stddef.h>, and 
<stdarg.h>, as well as <limits.h> 
and <float.h>. 


Regarding void Casts 


Public comments were received 
asking that program examples 
which disregard a function’s 
returned value — such as 


printte2™)3 


— be revised to show a void cast, 
as in 


(void} printe ("2"); 


After some discussion, it became 
clear that the C community now has 
a new style battle that rivals the 
intensity of the ‘‘braces’’ wars. 
There seem to be at least three posi- 
tions. 


(1) Satisfy lint: always void 
cast. Some functions, e.g. scanf, 
return a value that is of vital impor- 
tance to program _ reliability. 
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Syntax-checkers such as lint give 
warnings any time a returned value 
is ignored. Therefore, programmers 
should routinely test returned 
values (for reliability), should 
always use lint (or its equivalent), 
and when a returned value is being 
ignored, a void cast should be used. 
Because of the reliability advan- 
tages of checkers such as lint, this 
position is widespread among the 
UNIX community. 


(2) Avoid distractions: never 
use void casts. The contrasting 
view is that every use of a cast in a 
C program should prompt a ques- 
tion by the reviewer or maintainer 
as to the reason for the circumven- 
tion of normal typing. Accord- 
ingly, by this view, good C code 
contains very few casts, and those 
that appear should have compelling 
reasons. When style rules impose 
Casts on every third or fourth line of 
code, the truly important casts are 
lost in the noise. A strong majority 
of the committee appears to favor 
this position, because the vote (19 
for, 8 against, 7 abstaining) was to 
eliminate all examples of void 
casts, except in the example that 
shows you can do it! 


(3) Use void casts selectively. 
A third view favors the approach 
taken by some more recent lint-like 
Checkers, which allow selective 
disabling, on a function-by-function 
basis, of the ‘“‘ignored returned 
value’’ warnings. In particular, the 
functions memcpy, memmove, 
memset, strcat, strcpy, strncat, 
and strncpy (“‘group A,’’ say) sim- 
ply return one of their arguments; 
no useful purpose is served by any 
emphasis on their returned values. 


Some functions, — including 
mktime, time, and tmpnam 
(“group B’’), sometimes produce 
their desired result in the storage 
specified by a pointer argument, in 
which case the retumed value is 
irrelevant. 
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Finally, a large group of func- 
tions — atexit, fclose, fflush, 
fprintf, fputc, fputs, fseek, fset- 
pos, fwrite, printf, putc, putchar, 
puts, raise, remove, rename, 
setvbuf, system, ungetc, vfprintf, 
and vprintf (‘‘group C’’) — make 
use of their returned value to indi- 
cate the success or failure of the 
request. A strong case could be 
made for a style rule mandating that 
this success-or-failure be attended 
to in all calling instances, but rou- 
tinely applying void casts to ‘‘shut 
lint up’’ is no better than simply 
ignoring the return. 


I will conclude this discussion 
with some personal, unofficial opin- 
ions. Checkers such as lint should 
embody options to _ prevent 
‘“ignored-return’’ warnings for the 
functions in groups A and B. The 
Same option should be available for 


the functions in group C. However, | 


a more reliable programming style 
would be obtained from requiring 
that the group C returned values be 
attended to (with no void casts). 
This style should (a) not demand 
extra source lines per function invo- 
cation; (b) add little execution-time 
overhead; and (c) associate left-to- 
right without extra nesting. For 
example, add a local status variable 
to each function, with a short name 
to facilitate frequent usage and to 
avoid ‘‘right-margin sprawl’’: 


into 2} 
| a Eee Prats | 
Oki b=50$<iprinté(' 2"): 
LX svg <td 
Lf Ciok) 
msg ("write err(s)"); 


A more readable variant would 
define a macro: 


#define CHK ok &= 


to be used like this: 


CAR OF<- prinera™ 2 ys 
CHK 1 == scanf("%Sd", &n); 
CHK 0 == remove ("tmp1") ; 


Recognizing that these brief 
remarks have only scratched the 
surface, I hope that they will ini- 
tiate a wider discussion of these 
issues. [The C Journal will wel- 


come letters from our readers — 
Ed.] 


Corrections 


In my December 1986 report, 
Sstlib.kh should be stdlib.h, and 
EXIT FAIL should be 
EXIT FAILURE. 


Also, the closing sentence 
‘[T]he committee still expects a 
completed Standard by late 1986 or 
early 1987’’ should have said ‘‘late 
1987 or early 1988.’’ Rich Hall, of 
‘““Sniglets’? fame, has defined 
Checkuary to be the (variable- 
length) month that extends from 
January 1 until you stop writing the 
previous year on your checks! I 
must have written the December 
column during Checkuary. 


[Thomas Plum is Chairman of 
Plum Hall Inc, and author of 
several books on the C language. 
As Vice-Chair of ANSI committee 
X3J11, Dr. Plum is designated by 
the committee to handle communi- 
cation to and from the public.] 
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A Letter to the 


ANSI C Committee 
prom 2. M. Ritchia 


The following letter was written 
by Dennis M. Ritchie and addressed 
to Jim Brodie (ANSI C X3J11 
Chairman) and Larry Rosler (Edi- 
tor of the ANSI C Draft and 
AT&T's principle X3J11 represen- 
tative). It is dated October 20, 
1986 and copies of it were circu- 
lated to all X3J11 members. It is 
reprinted here with Dennis’ kind 
permission. 


The publication of the official 
draft of the C standard provides a 
good opportunity for me to thank 
the members of the X3J11 commit- 
tee, all the people at AT&T who 
contributed so much to it, and espe- 
cially you, for immense and admir- 
able efforts in producing this docu- 
ment. 


As the committee members 
know, I took no part in their deli- 
berations, and only very rarely 
made suggestions. Indeed, my only 
strongly-stated bit of advice, that 
the new-style function definitions 
and declarations [prototypes] were a 
perilous undertaking, was in the end 
set aside by the committee. My lack 
of participation did not mark 
absence of interest, but instead 
reflected growing trust in the intelli- 
gence, good sense, and vigor of the 
committee in general and especially 
those who, in effect, acted as my 
representatives. 


Although I spared myself the 
years Of travel, argument, 
compromise, and hard work poured 
into the draft standard, I appreciate 


your labors most deeply, because 
writing the C manual that appeared 
in the White Book [K&R] was one 
of the hardest things I have ever 
done. Committing such a document 
to print filled me with alternating 
feelings of unwanted power and 
utter impotence. A_ carelessly 
specified detail may condemn 
thousands to confusion and error, 
but simply proclaiming that some- 
thing must be, does not make it so. 
To sort out what must be specified 
from what must remain unsaid, to 
judge which changes are possible 
and which are not: here are the 
agonizing decisions. 


By the time the committee 
undertook its task, it was clear that 
both the pressures for change, and 
the constraints on its freedom to 
innovate, were already stronger than 
anyone could have imagined ten 
years ago: vested economic 
interests, machines and _ environ- 
ments vastly different from C’s 
early hosts, new language ideas, old 
ideas never properly considered, all 
conspired to confound _ the 
standard-makers. 


Therefore, it is with great pleas- 
ure, and a sense of relief that they 
have done so well what I could 
never have done, that I congratulate 
the members of X3J11 on writing a 
Standard that is readable, sensible, 
and usable. Well done! 


Gratefully yours, 
Dennis M. Ritchie 
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Implementing Standard 
Communications 
Protocols in 
C 


© 1987, Donald Berryman 


Intemational data communications standards have been developed to allow the dissimilar architectures of devices 
to be transparent to public and private data communications networks. Most standard protocols are defined as finite 
State machines or state/event tables. 


A finite state machine is an abstract device having a finite number of states (memory) and a Set of rules 
whereby the machine’s responses (state transitions and output sequences) to all input sequences are well 
defined. 

System Network Architecture Format and Protocol Manual 

— International Business Machines Corporation 


This article will use X.25 as an example to show how to implement multi-layered event-driven protocols in C. 
The full implementation of X.25 is beyond the scope of this article. However, the methods discussed will provide a 
foundation for anyone wishing to do so. This article assumes a knowledge of the C programming language and 
some knowledge of data communications. 


The first step in implementing X.25 software is to get documentation from different sources. The CCITT Red 
Book (Volume VIII Fascicle VIII.3: Data Communication Networks Interfaces) is the indispensable, authoritative 
and unadulterated definition of the protocol. However, the state tables and diagrams in the CCITT Red Book 
describe states as perceived by the DCE (the network side) and actions taken by the DCE. It is also somewhat 
ambiguous. The International Standards Organization (ISO) also publishes an excellent definition of X.25 (Data 
Communication — X.25 Packet Level Protocol for Data Terminating Equipment) with state tables and diagrams 
from the DTE point of view. I would recommend obtaining additional documentation from your target network. 


CCITT Recommendation X.25 


CCITT recommendation X.25 defines the interface between a DTE (Data Terminal Equipment) and a DCE (Data 
Circuit terminating Equipment) in a packet switching network. X.25 represents the lower three layers of the ISO 
Open Systems Interface (OSI) model: the physical layer, the data link control (DLC) layer (frame level) and the net- 
work layer (packet level). 


The physical level (level 1) governs the electrical and procedural characteristics of the interface required to 
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Eco-C88 C Compiler: 


A full, professional C compiler with many ANSI enhancements at an 
unbelievably low price. 


* Prototyping, enum, void data types, plus structure passing & 
assignment * All operators and data types * Over 200 library 
functions * cc and mini-make for easy use * 8087 support * ASM or 
OBJ output * Lint-like tiered error messages * Fast code * CED 
editor (edit-compile-link from within the editor) * Expanded user’s 
manual * Not copy protected * All for only $59.95! 


M Eco-C88 Flexi-Graph Graphics Package 


Everything you need to write dramatic graphics effects into your 
Eco-C88 C programs. 


* EGA, CGA, and Z100 support * Over 100 graphics functions (many 
are PLOT-10 compatible) * Most assembler support routines are 
outside small model code-data * Write thru BIOS (for compatibility) 
or to memory (for speed) * Graphics function help from CED editor 
* World, pixel or turtle color graphics modes * 47 standard fill 
patterns, 17 line dashing patterns, Hershey fonts, plus user 
defineable fill, dash, and fonts * Supports view areas, rotateable 
fonts, clipping, arbitrary fill areas, extensive error checking, 
examples, and user’s manual * Only $39.95 


M Eco-C88 Windowing Library 


Use this library to build pop-up windows, help windows, selection 
menus, special effects—anywhere you need an attention getter. 


* CGA and EGA support * Control any program that goes through 
the BIOS * Use up to 255 windows * No special window commands 
— use plain old printf(_ ) to write to a window * Resize and move 
windows * Custom window titles and borders * Can be used with 
ANSI device driver * Most window code-data are outside small model 
* User’s manual and examples for only $29.95 


HM Ecosoft Librarian 


Combine your modules, functions, and subroutines into your own 
library for easy link commands. Compatible with any standard 
MSDOS OBJ files * Add, delete, and extract from a library * Get 
table of contents or index of a library * Combine libraries, control 
library page size, use switches for combinations, process complex 
library requests, use wildcards, and do library directives from 
command files * Complete with user’s manual for only $29.95 


HM Developer’s Library 


Contains the source code for for all library functions, including the 
transcedentals, memfiles, and those written in assembler. $25.00 
with order, $50.00 if ordered later. (Sold only to Eco-C88 owners.) 


2 Ecosoft Inc. 3s 
aa 6413 N. College Ave. — 
a yn Indianapolis, IN 46220 seems 


Eco-C8&8 C compiler requires an IBM PC, XT, or AT (or compatible) with 
256K of memory, 2 disk drives and MSDOS 2.1 or later. 


C Programming Guide 
(Purdum, Que Corp.) 


The second edition of the B. Dalton bestseller. 
Perfect for those just getting started with C. 
Includes discussion of many X3J11 ANSI Standards 
Committee recommendations. Many error messages 
from Eco-C88 give page references to this book. 
Price is $20.00 plus $2.00 shipping. 


C Self-Study Guide 
(Purdum, Que Corp.) 


Using a question-answer approach, this book is 
filled with shortcuts, tips, techniques, and traps to 
avoid when learning C. Price-is $17.00 plus $2.00 
for shipping. 


C Programmer’s Library 
(Purdum, Leslie, Stegemoller, Que Corp.) 


Another B. Dalton bestseller. An intermediate C 
text for the programmer that wants to get the most 
from the language. Contains source code for many 
functions including an ISAM file handler. Price is 
$22.00 plus $2.00 for shipping. 


To order, call or write: 


1-800-952-0472 ~~ = 1-317-255-6476 


(for orders) (tech. info.) 


ORDER FORM CLIP & MAIL TO: 
Ecosoft Inc., 6413 N. College Ave., Indianapolis, IN 46220 
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activate, maintain and deactivate the physical circuit between the DCE and DTE. 


The frame level (level 2) provides a vehicle for transmitting packets between the DTE packet level and the DCE 
packet level. Error detection and recovery are provided to guarantee data integrity. The frame is the unit of 
transmission. Each frame consists of a leading flag (Ox7e), an address field, a control field, a cyclic redundancy 
check (CRC) field and a trailing flag. Theresare three types of frames: Supervisory frames, Unnumbered frames, 
and Information frames. Supervisory frames are used to provide link supervisory functions such as acknowledg- 
ment on incoming frames and requesting retransmission of bad frames. Unnumbered frames are use to provide link 
control functions. Information frames are used to send information (packets) from the packet level. Each I-frame 
will contain only one packet of information. 


The packet level (level 3) deals with the establishment and management of switched virtual circuits (SVCs) and 
permanent virtual circuits (PVCs). Up to 4096 virtual circuits (VCs) can exist on a single physical link. A virtual 
circuit is a communications pipeline that is established via a call request packet. Each VC is assigned a logical chan- 
nel number (LCN). Flow control at the packet level is maintained for each individual VC. The data packet is to the 


packet level what the information frame is to the frame level. It is used to send information (data) from higher level 
processes. 


Task Management 


In order to implement a multi-layered protocol, task management and task communication services need to be 
provided. These services may be provided by a real time operating system. For this example we will assume that 
we have chosen to implement stand alone code on an intelligent communications board with no resident operating 


system. Low level code is needed to service hardware interrupts. Even the low level code can be implemented 
_ almost entirely in C. 


A scheduler routine can provide task management and task communication via event cell queues, linked struc- 
tures that contain information regarding real time occurrences. An event may be a timer expiration, an incoming 
frame, a request from the host to establish a virtual link or any number of things. An event cell can be queued for a 
task by interrupt service routines or other layers. In this example event cell structure, a NULL value in the member 
labeled next implies that this is the last event cell in the queue, and a NULL value in the member labeled buf 
indicates that there is no buffer associated with this event: 


struct cell { 


unsigned char event; /* Event type */ 
unsigned char task; /* source task */ 
struct buffer *buf; /* buffer pointer */ 
struct cell *next; | /* forward link */ 
bs 
struct cell *frame q; /* task event queue */ 
struct cell *packet_q; /* task event queue */ 
struct cell *free q; peetres” event cells. *+/ 
struct cell *free tail; /* last free cell */ 


All tasks and interrupt service routines need external references to the event cell queues. The free q isa 
pointer to the first free event cell in a pool of queued pre-allocated event cells. A pointer to the free queue tail (the 
last event cell in the queue) is provided to avoid the necessity of walking through each element in the queue in order 
to add an element to the end. I did not include a tail pointer to the task event cell queues because, hopefully, events 
will be processed fast enough that walking through the task event queues would be a relatively short stroll. Because 
a NULL value indicates the end of the queue, the following can be used to reach the end of a event cell queue: 


struct cell *ptr; 
while (ptr->next) 


Dil: = PEI-SneXxL; 
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The following functions get cell and free cell would provide the mechanism for obtaining and freeing 
event cells. 


void fre¢ cell(c p) 
Struct: cell *c p; 
{ 


Cc p->next = NULLCELL; se Clear FlLink <*/ 
free tail->next = c p; /* link to queue */ 
free tail = cp; /* set tail pointer */ 


struct cell *get cell () 
{ 
struct cell *ptr; 


if(free_ q) { 
ptr = tree q; 
free. gq = ptr->next; 
ptr->next = NULLCELL; 
return (ptr); 


else 
return (NULLCELL) ; 


The scheduler examines the queues and starts the task based on priority. In OSI model protocols each layer 
builds upon the services provided by the next lower layer and represents the sum of its services and the services of 
all lower layers to the next higher layer. Therefore, the highest priority must be given to the lowest level. To 
ensure integrity of the system, frame level events must be processed before packet level events. 


void scheduler () 

( 
extern struct. ceil *frame. aq, .*packet- gq; 
extern void frame task(),packet_task; 


while (TRUE) { 


while (frame _q) { /* service frame level events */ 
frame _task(frame_q); /* handle event */ 
frame_q = frame _q->next; /* get next event */ 


if (packet_q) { /* event for packet level ? */ 
packet _task(packet_q); /* handle event */ 
packet _q = packet _q->next; /* get next event */ 
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This mechanism guarantees that all lower layer events are handled before events for the next highest level. This 
method could be extended to include other layers of the OSI model. A transport layer could be added at this point 
by inserting: 


else if (trans q) { 
trans task(trans_q); /* Randle event */ 
trans q = trans_q->next; /* get next event */ 


Transport services are beyond the scope of X.25. We will assume for our implementation that the transport 
layer (if any) is implemented on the host. It is necessary to add one more task: the host interface. Specific imple- 
mentation will depend on the hardware. | 


If interrupt services routines cannot access the task queues or if the host bus interface cannot be interrupt driven, 
a method of polling for events may have to be included in the scheduler. Care should be taken to not overload the 
scheduler loop with tests for exceptional occurrences. oo time wasted there will have a dramatic negative effect 
on the throughput of the system. 


Buffer Management 


Without an operating system we must provide buffer management for ourselves. A queue of buffers must be 
pre-allocated for incoming frames, and they must be large enough to hold the maximum size frame, an I-frame con- 
taining the maximum size data packet. 


Any of a number of buffer management schemes could be used. The thing to keep in mind is to avoid copying 
data from one buffer to another. When an incoming I-frame arrives, it is written into the buffer address that was 
given to your DMA controller. At that point the frame level must send its acknowledgment and put the address of 
that buffer into an event cell and put that event cell into the packet task event cell queue. The packet level is then 
responsible for freeing the buffer or reusing that buffer for a response to the DCE. 


Event Processing 


When an event occurs, the resultant action is determined by the state of the interface. CCITT recommendation 
X.25 Annex B and Annex C describe the Finite State Machines (FSM) that govern action and state transition at the 
packet level. 


The states that govern action at the packet level are defined in three FSMs: The restart (R1 — R3) states, the 
logical channel (P1 — P7) states and the data flow (D1 — D3) states. The restart states are global in scope and 
apply to all VCs. The logical channel states and the data flow states apply to a particular VC or logical channel 
number (LCN). The states are hierarchical. When the packet level goes into state R1 (packet level ready) all SVCs 
are put into P1 state and all PCVs are put into P4/D1 state. The D states are valid in P4 (data transfer state) only. 
These FSMs are not complete. They only deal with incoming traffic as events. Other events that need to be 
included in your implementation are timer expirations and requests from higher levels. 


Implementing Finite State Machines in C 


The most obvious way to implement FSMs would be with nested switch statements where you would switch on 
the state and then in the case for a specific state you would switch on the event: 


/* EVENTS */ 


#define RSTRT_IN 0 /* restart indication packet */ 
#define RSTRT_CN 1 /* restart confirmation packet */ 
#define DATA 2 /* data packet */ 
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We cut our teeth on UNIX, but have become famous on MS-DOS, which we enhanced with our UNIX-like DOS 
Helper ™ utilities: find (including tar), fgrep, cat, 1s, mv, tail, unig, and wc; and our superior optimizing compilers: 
Professional Pascal ™ and High C ™ on the PC are now well-respected by organizations such as Ansa, 
Ashton-Tate, AutoDesk, Boeing (BCS), Daisy Systems Corp., Deloitte Haskins & Sells, Digital Research, GE, IBM, 
Lifetree, Migent, Multimate, NYU, Silvar-Lisco, Sky Computers, Symantec, Xerox/Ventura, ...and Computer Lan- 
guage magazine; Dr. Dobbs’ Journal; PC Tech Journal; PC Magazine; the Journal of Pascal, Ada, and Modula-2... 


We supply the first, and still only, compilers generating 32-bit protected-mode code for the 80386 under 
MS-DOS. And our newly upgraded MS-DOS real-mode compilers were used by Symantec for their Q&A™ product 
to exploit the power of the 80386 real-mode instruction set. (Just released: HC v1.4 and PP v2.7, May 1987.) 


Our C Validation Suite will blow your C compiler out of the sea, while our C compiler tracks the emerging ANSI 
Standard and generates tighter code with far better lint-like feedback help than competing compilers. 


And you'll love Professional Pascal's Ada-like packages, true data abstraction, C-like bit manipulation, and much 
more, along with the tight code that is linkable with High C, or other C, object modules (and vice versa). 


Our Translator Writing System (TWS) goes far beyond LEX and YACC, with fully automatic error recovery... 
All uniformly implemented on UNIX, VMS, CMS, MS-DOS, FlexOS... 
Professional software developers in need of industrial-strength tools should contact: 


; | a7 MetaWare Incorporated 
TH ite il | ae 903 Pacific Avenue, Suite 201 
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(408) 429-6382 (META) 


INCORPORATED Telex: 493-0879 (META Ul) 


| and Cross 
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© 1987 MetaWare Incorporated. MetaWare, High C, Professional Pascal, and DOS Helper are trademarks of MetaWare Incorporated. Others/owners: Ada/DoD; Apollo/ 
Apollo; Atari/Atari; DEC,VAX,VMS/DEC; FlexOS,GEM-DOS/Digital Research Inc.; IBM,RT PC/IBM; MS-DOS/Microsoft; Q&A/Symantec; Sun/Sun; UNIX/AT&T. 
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/* actions */ 


void 


Switch ( 


case RIL: 


case R2: 


rstrt rat}, 


rstrt_con(), Ex 
s len st(), {* 
ve_switch(), /* 
discard(); i* 


State) { 


Switch(event) { 


case RSTRT_IN: 
rstrt_con(); 
state = R3; 
break; 


case RSTRT CN: 
rstrt_rq(); 


state = R2; 
break; 

case DATA: 
len switch(); 
state = RI; 
break; 


break; 


Switch(event) { 


case RSTRT_ IN: 
case RSTRT CN: 
s ben: st’); 


state = R3; 
break; 

case DATA: 
discard(); 
state = R2; 
break; 


break; 
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send restart confirmation */ 
set LCN states (SVCs to Pl 
execute virtual circuit switch (P states) */ 


no action, 


release buffer */ 


PVCs to P4/D1) */ 


With many states and many events, this approach could yield code that is difficult to read making it difficult to 
debug and maintain. The multiple tests of the state and event would also make it inefficient at run time. 


The way a FSM is described, the state/event table, provides a clue to a more efficient implementation. The 
state/event table is a two dimensional array in which each element is an action plus state transition. The logic is in 
the matrix. In C the matrix could be implemented as two static arrays, one for actions and one for state transitions. 
It could also implemented as an array of structures where the members of the structure would be the state and the 
action. An action element is a pointer to a function: 


Struct: tsm if 
char next state; /* state transition */ 
int (*action) (); /* pointer to function */ 


rs 


/* EVENTS */ 


#define RSTRT_IN 0 /* restart indication packet */ 
#define RSTRT CN 1 /* restart confirmation packet >*/ 
#define DATA 2 /* data packet */ 


/* actions */ 


void rstrt rq()-, /* send restart request */ 
rstrt_con(), /* send restart confirmation */ 
s_ len _st(), /* set LCN states (SVCs to Pl : PVCs to P4/D1) */ 
ve fsm(), /* execute virtual circuit fsm (P states) */ 
discard(); /* no action, release buffer */ 


Struct fsm restart [MAX _R_EVENTS] [MAX R STATES] = { 
[7K IKK KIKI II II IOI III IO I IIR IKK I / 


/* | States bail f 
/* Events | R1 R2 R3 x/ 
[RRR KK KKK KKK KKK KKK KK KKK KKK KKK KKK KKK KKK KKK KK KK KK KKK KKK KERR KEK KK / 
f* ROTRE . IN. * 7 R3/.TStre con, Ri Sten st, RZ; ‘rgtrgord, 
/* RSTRT CN */ R2, rstrt rq, Rl, s len st,  R2, rstrt rq, 
/*: DATA *f Rie we ism, R2, “dastard, R2, rstrt rq 


he 


With this array of structures defined, the web of nested switch statements could be replaced with the following: 


static char r_state 


void restart fsm(ecell). 
struct event cell *ecell; 


{ 


Struct. Ls *ptr; 


ptr = restart [ecell->event] [r_ state]; 
r_ state = ptr->state /* set new state */ 
* (ptr—->action) (ecell); /* execute required action */ 
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The executable code to implement a FSM would remain the same no matter how many states and events had to 
| be implemented. This method avoids testing the value of the current state of the interface and the event against 
: multiple constants. Implementing a FSM using nested Switch statements requires code for making total states + 
(total states * total events) tests. Using the static FSM matrix eliminates the need to test state and event completely. 
: The main benefit derived from this method is increased throughput (which is the name of the game in data commun- 

ication). : 


It should be noted that for either method a function is required to validate the event. When the frame level task 
queues an Information frame for the packet level, it is simply information. Packet types only have relevance at the 
packet level. So the packet level must extract the packet type and revise the event field in the event cell in order to 
perform action on the basis of the packet type. 


Another benefit from using the static FSM matrix is that it makes the code more readable. I will avoid the 
phrase self documenting which is often used as a excuse for not documenting the design process properly. How- 
ever, the FSM in the design document and the static initialization of the FSM array in the code will look almost the 
same. This makes it easy to walk through the code. It also provides a reference for verifying compliance with the 
target network’s certification procedure. Comparing your array with the certification documents state/event matrix 
can help find problems before you are knee-deep in run-time bugs. 


The functions that perform the prescribed action in the FSM must be streamlined. It is better to define a new 
event type and have a task queue a event for itself than to spend too much time handling a single event. 


FSMs are used extensively in communication protocol definitions. The FSM is an excellent design concept. The 
static FSM matrix is a way to quickly convert the design into efficient code that is easy to test and maintain. 


| [Donald Berryman is a senior design engineer for ADC Telecommunication Inc. and has been involved in communi- 
cation software development for TITN Inc. and NCR Comten Inc.] 
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CRC: 
A Semi-Bytewise 
Calculation 


Curtis Wright 


Abstract 


The CRC (Cyclic Redundancy Code) calculation 
was developed to validate computer data transmitted 
or stored in bit streams. Its ability to detect the kinds 
of errors that are expected in a bit stream is responsi- 
ble for its wide spread use in communications. There 
are, however, many other applications to which CRC 
may be applied. A program that creates a squeezed or 
encrypted file may use CRC to validate the reverse 
process. A program that modifies a multi-user data 
base can use CRC to verify that a record has not been 
changed between the read and update steps. Making 
the CRC calculation available for all of these applica- 
tions requires an algorithm that is both compact and 
fast while being easy to implement in a high level 
language. Such an algorithm is presented in this 
paper. 


Introduction 


The CRC calculation process is analogous to a 
simple division problem. A dividend is divided by a 
divisor to produce a quotient and a remainder. In the 
CRC calculation the data record is the dividend, which 
is divided by the CRC generation polynomial which is 
the divisor. The quotient of the operation is not used, 
but the remainder is the CRC. The biggest difference 
between division and the actual CRC calculation is 
that all operations in the CRC process are performed 
using bitwise modulo 2 arithmetic. Given a degree of 
abstraction, the mechanics and the logic of the two 
processes are identical. 


Although it is possible to select many CRC gen- 
eration polynomials, there are a small number that 
have been established as standards. The most com- 
mon polynomials used to generate CRCs in micro 
computers are CRC-16 (from BISYNC communica- 


tions) and the polynomial associated with SDLC (Syn- 
chronous Data Link Control). These polynomials are: 


SDLC MEX LG HOMERED KS: HS Te 210 2T base 16) 
ERC=16 KEX16 +98 *E5 4 x¥*2 & 1 =: 18005. (base—16) 


The binary value of the message or record is 
divided by the binary representation of one of these 
generation polynomials. 


For the purposes of this article, we will be using 
the SDLC polynomial as it is used in implementations 
of the XMODEM communications program. This 
method differs somewhat from the standard, but has 
found wide acceptance in a variety of programs in and 
out of communications. 


Calculation of a CRC using the method associated 
with XMODEM is characterized by several facts. 
First, there is no preconditioning or post-conditioning 
of the CRC. That is, the CRC is initialized to zero 
and the calculated CRC is not modified before use. 
Second, the calculation process only includes data 
from the record or records being processed. Record 
headers and trailers are excluded. Finally, the data is 
presented to the calculation starting with the high bit 
of the low byte through to the low bit of the high 
byte. This last fact greatly simplifies the process of 
calculating the CRC in a high level language. 
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CRC Division Schemes 


There are two basic schemes for performing the 
CRC division process. The first is equivalent to long 
division and will be referred to as the intermediate 
remainder method. The second method calculates an 
intermediate product rather than a remainder and will 
be referred to as the partial product method. This 
method is the one most seen in hardware implementa- 
tions. The relationship between the two methods can 
be seen in Figure J. The intermediate remainder is 
produced by subtracting a digit product from the pre- 
vious remainder. The partial product is generated by 
adding each digit product to a sum. In the partial pro- 
duct method the intermediate remainder at any given 
step may be generated by subtracting the partial pro- 
duct from the divisor. This is an important fact for 
understanding this method. 


US Bs 
129 )670268 000000 pp 
645 +645 
252638. 27 645000 pp 
129 £129 
12368 ir 657900 pp 
1161 +1161 
7158 235 669510 pp 
645 +645 
113) ax 670155 pp 


Long Division and Partial Products 
Figure 1 


Algorithms that have been generated to calculate 
CRC in software use both methods for performing the 
divide. Favorable attributes of the partial product 
method make it especially useful for byte-wise and 
semi-bytewise calculations. Therefore, this is the 
method that will be used in the routines presented 
here. 


CRC Generation Algorithms 


Within either of the two types of CRC calcula- 
tions, there are three types of algorithms employed to 
generate the CRC. The first, known as the bitwise 
calculation, processes each bit in the message much 
like what is done in hardware. In software, this tech- 
nique is the most compact but, it is by far the slowest. 
The second method, known as the bytewise calcula- 
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tion, uses a table of predicted partial products for each 
of the 256 byte configurations. Values from this table 
are added and shifted in the partial product to generate 
the CRC. This technique is the fastest calculation, but 
requires 512 bytes of memory to store the table of 
predicted partial products. The last method, known as 
the semi-bytewise calculation, attempts to predict the 
value of a partial product table entry for use in the 
CRC calculation. Current implementations of this 
technique are based on the prediction of what would 
be in a CRC shift register at eight bit intervals. The 
success of this method is that it is much smaller than 
the full table version while retaining much of the 
speed advantage. However, the method needs to be 
implemented in assembly language which can be a 
considerable disadvantage. 


By observing the techniques of calculating partial 
products, it is possible to implement an alternative 
semi-bytewise calculation that has all of the size and 
speed advantages of the usual method yet can be 
easily implemented in any high level language having 
shift and exclusive-or capabilities. 


The first fact of partial product calculation that 
needs to be observed is how the product is generated 
in the bitwise method. Figure 2 shows a divide opera- 
tion using partial products. In this abbreviated exam- 
ple, the CRC generation polynomial is x**3 + lor 
binary 1001. At each step, the partial product is 
shown with brackets indicating the contents of an 
appropriate CRC register. 
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CRC Calculation by Partial Products 
Figure 2 
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schedule. Plum Hall textbooks con- 
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The new Plum Hall Validation 
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The Plum Hall Validation Suite is 
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Script generated C, provide compre- 
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Note that there are no intermediate remainders. 
Rather, each step accumulates a partial product of the 
dividend and the partial quotient. The significant 
feature of this example is that the upper bit of the 
CRC register and the associated data bit are what con- 
trols the calculation process. For any step of the divi- 
sion, the upper bit of the ‘‘intermediate remainder’’ is 
what determines whether to accumulate zero or the 
polynomial constant in the partial product. This bit 
can be generated with an exclusive-or of the upper bit 
of the CRC register and the associated bit in the divi- 
sor. 


There is one more thing about Figure 2 that 
should be discussed. Note that the divide process con- 
cludes with the partial product extending past the nght 
side of the divisor. This results from the fact that the 
divide operation is controlled by the upper bit of the 
CRC register and its associated data bit. By the time 
the last data bit gets to the point of being included in 
the calculation, it has shifted to the left of the CRC. 
This fact makes it unnecessary to append zero bytes to 
the message as required in some algorithms. 


Some C Examples 


Figure 3 shows a C code fragment that imple- 
ments the bitwise calculation process. All of the vari- 
ables in the fragment are 16 bit integers. The 
data_reg variable is filled with one or two bytes 
from the data record so that the first byte is the upper 
eight bits and the next byte is the lower. This permits 
the sign bit to be used to detect the exclusive-or result 
which is the upper bit of the intermediate remainder. 
The sign of the exclusive-or of the crc and data regis- 
ters is negative when the upper bit of the intermediate 
remainder is a 1. If true, the CRC generation polyno- 
mial is added to the partial product. The calculated 
CRC is in the crc_reg variable after the last byte 
of the record is processed. 


while (bits--) { 
ct (cre: reg." dataiimeg)) <0) 
Cre. Teg acs is 
Cre Teg: feces i 
} else 
Gre req news ky 
Gate Teg <<s-1¢ 


Bitwise CRC Calculation 
Figure 3 


On a bitwise basis, everything happens as a result 
of the upper bit of the intermediate remainder. This 
bit being a 1 causes the partial product for the bit to 
be added to the CRC with an exclusive-or. To apply 
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this to a bytewise calculation, it is necessary to calcu- 
late a bytewise intermediate remainder. The partial 
product associated with this byte could then be added 
to the CRC to get the same result obtained with eight 
bitwise operations. This is precisely what happens in 
the table driven CRC calculation. 


Figure 4 shows a C code fragment that imple- 
ments the bytewise calculation process. All of the 
variables in the fragment are 16 bit integers except 
buffer which is a character pointer into the data 
record. The upper byte of the intermediate remainder 
is used as an index into a table of bytewise partial pro- 
ducts and is represented by the variable n. As with 
the bitwise process, this byte is generated out of the 
exclusive-or between the upper byte of the CRC regis- 
ter and its associated data byte. After shifting the CRC 
register one byte, the partial product indexed in the 
table is added to the CRC with an exclusive-or. The 
calculated CRC is in the crc_reg variable after the 
last byte of the record is processed. 


while: (count=—) <-{ 
n = (crc reg >> 8) & OxFF; 
n *= (*buffer++ & OXxFF); 
cre reg <<= 8; 
Cre Lege = COGe it bi En] > 


Bytewise CRC Calculation 
Figure 4 

What remains is to calculate a table of bytewise 
partial products. As can be seen in Figure 5, the byte- 
wise values are calculated using the bitwise process. 
In this case, each possible byte code, represented by 
the n index, is placed in the upper half of variable 
ch. The associated partial product, pp, is calculated 
using the bitwise process and then stored in the 
code tbl at n. Note that this technique is consid- 
erably different from other table calculation algorithms 
which use an abstraction from CRC shift register con- 
tents. 


for (n = 0; n < 256; n++) { 
ch=n << 8; 
pp = 0; 
for (bits = 8; bits--;) { 
Lé Chop eo eh) <0) 
pp <<= 1; 
pp *= 0x1021; 
} else 
pp <<= 1; 
ch <<= 1]; 


} 
code tbl[n] = pp; 


Partial Product Table Calculation 
Figure 5 


The bytewise CRC calculation was created by 
removing the repetitive bit processes and replacing 
them with a table. The task for a semi-bytewise cal- 
culation is to put the bit process back with a much fas- 
ter bit algorithm. Observing the contents of the table 
(see Figure 6) generated by the code in Figure 5 will 
provide some clues as to how this may be accom- 
plished. The objective is to find a pattern in the table 
that may be used to duplicate an entry with a very fast 
process. 


The table contains a partial product for each of the 
possible bytewise intermediate remainders (byte code). 
The relationship between the byte code and the partial 
product exhibits a pattern that can be used to calculate 
the table value from the byte code. The beginning of 
such a pattern can be seen in the first 16 table entries 
of Figure 6. Note that 16 bits of the CRC generation 
polynomial code (1021) are duplicated for each bit of 
the byte code. For a byte code of one, the polynomial 
code is stored in line with the 1 bit. Likewise, with 
byte codes two and four, the polynomial code is stored 
in line with the second and third bits respectively. 
When the byte code has multiple bits, the polynomial 
code is duplicated in each bit position, as can be seen 
at indexes 3, 5, 6, and so on. Reversing the perspec- 


Vitamin C Difference 


_ With Vitamin C, your applications come 


AARNE 


VITAMIN 


It’s good for your system! 


High Level Functions 


Standard help handler provides context 


tive for this observation reveals that the byte code is 
duplicated for each bit of the polynomial code. It 
follows that accumulating the byte code for each bit of 
the polynomial code is equivalent to accumulating the 
polynomial code for the each bit of the byte code. 
However, while we never know which bits exist in the 
byte code, we always know where the bits are in the 
polynomial code. This is the root of the new semi- 
bytewise algorithm. 


There is a hitch in the pattern.that can be seen in 
the predicted codes at indexes above 15. This is the 
point where the predicted partial products have more 
than 16 bits (meglecting the high bit of the binary 
polynomial). In the shifting process of the bitwise pro- 
cedure, the bits that leave the upper end of the CRC 
register are ignored. What can not be ignored is the 
influence those bits have on the _ intermediate 
remainder which in turn affects the resulting partial 
product. The 1-bits emerging from the upper end of 
the CRC register create a zero bit in the intermediate 
remainder negating the accumulation of the polyno- 
mial in the partial product and altering the pattern 
observed in the first 16 table entries. Therefore, an 
extension to the pattern is needed to account for this 
alteration. 
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The deviation in the pattern is caused by the 1-bits 
that emerge from the upper end of the CRC register. 
They, in effect, preclude the polynomial code from 
being accumulated in the product by making the upper 
bit of the intermediate remainder a zero. To match 
this effect in the bytewise algorithm, it is necessary to 
back out those bits that would be in the overflow code. 
The example in Figure 7 illustrates the relationship 
between the byte code and the overflow bits. The first 
product on the left is created by direct application of 
the shifting pattern. The second product is produced 
for the four overflow bits and is subtracted from the 
first product with an exclusive-or. The result is the 
correct table value. Figure 7 also shows that the same 
result is produced when the byte code is modified 
before calculating the partial product. 


EF os F = FQ 
1021 1021 1021 
FF F FO 
1FE 1E LEO 
EF EF FO 
EFIF = FIEF = LEFO 


The general rule for applying this technique is that 
any code that would be emitted from the top of the 


Figure 7 


static int code tb1[256] = { 


OxX0000, 
OX8108, 
OX1231, 
0X9339, 
OXEFIF, 
OX6E17, 
2; 


OX1021, 
0X9129, 
0X0210, 
0X8318, 
OXFF3E, 
OX7E36, 


OX2042, 
OXA14A, 
OX3S2Z73, 
OXB37B, 
OXCF5D, 
OX4E55, 


* C041 28 
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0X3063, 
OXB16B, 
OX2252, 
OXA35A, 
OXDF7C, 
OX5E74, 


Partial Product of FF and 1021 


0OxX4084, 
OXC18C, 
OX52B5, 
OXD3BD, 
OXAF 9B, 
OX2E93, 


OX50A5, 
OXD1AD, 
0X4294, 
OXC39C, 
OXBFBA, 
OX3EB2, 


CRC register must be subtracted from the byte code 
before the bytewise calculation. This works very well 
for many polynomial codes like 1021 because the dis- 
tance between the upper bit and the top of the register 
keeps the overflow small. For others polynomials like 
that of CRC-16, the polynomial code has a bit that is 
too close to the top. As can be seen in Figure 8, a 
high bit in the polynomial code causes large overflow 
bit codes. These overflow codes then propagate to a 
second and third modification to the byte code. What 
is more, if there is more than one bit in the upper byte 
of the polynomial code, the problem becomes even 
more complicated. In any case, for polynomial codes 
that have less than two bits in the their upper byte and 
the upper three bits clear, the algorithm is exceptional. 


Figure 9 shows a C code fragment that imple- 
ments this technique in a new semi-bytewise calcula- 
tion process. All of the variables in the fragment are 
16 bit integers except buffer which is a character 
pointer into the data record. The upper byte of the 
intermediate remainder (byte code) is calculated on 
lines one and two. As with the table process, this byte 
is generated out of the exclusive-or between the upper 
byte of the CRC register and its associated data byte. 
The third line shows the modification of the byte code 
by the exclusive-or of the code with its upper four 
bits. After shifting the CRC register one byte, the par- 
tial product is calculated and added to the CRC by 
adding and shifting the byte code for each bit in the 
polynomial code. A full implementation of this tech- 


OX60C6, 
OXE1CE, 
OX72F7, 
OXF3FF, 
OX8FD9, 
OXOEDI, 


OX70ET7, 
OXFI1EF, 
OX62D6, 
OXE3DE, 
OX9FF8, 
OX1EFO 


Partial Product Table (Abridged) 
Figure 6 
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Partial Product of FF and 4003 
Figure § 


nique is provided in Listing 1. 


code = (crc reg >> 8) & OxFF; 


code “= (*buffer++ & OxFF); 
code.*= code >> 4; 

cre reg <<= 8; 

Cre reg “= code; 

code “<<=. 5; 

Cre. Feg os eodes 

code <<=' 7; 

ere Treg-o=- code; 


Semi-Bytewise CRC Calculation 


Figure 9 
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The last question to be answered is, how fast is 
this technique? Timing tests were conducted on rou- 
tines containing the code fragments presented earlier. 
The routines were constructed with similar structure 
and application, and were run against the same data. 
The bitwise calculation took 15 seconds to complete 
the test while the table driven bytewise routine took 3. 
The time taken by the new semi-bytewise calculation 
was just 4 seconds. 


The new semi-bytewise CRC calculation has a size 
similar to the bitwise routine, a speed that is close to 
the table driven routine, and the portability from a 
high level language. 


Curtis Wright KKKKKKKKKKKKKKEK 


This routine calculates a CRC (Cyclic Redundancy Code) 
for a block of data having one or more records. 
The method used illustrates the semi-bytewise partial 


product CRC calculation. 


Data is. presented to the calculation in left to right 


character order, 


upper bit first. The polynomial used 


is derived form the SDLC standard and applied in the 


fashion of XMODEM. 


The code for the polynomial is 1021. 


INPUT 

buffer = A character pointer to the buffer containing 
a record to be processed. 

count = An integer containing the count of bytes in 
the record buffer. 

crc = An unsigned integer containing zero or a 
previously calculated CRC. 

OUTPUT 

scrcp () = An unsigned integer containing the 
calculated CRC. 

USAGE 


This routine is implemented as a CRC calculation 
subroutine. One or more records may be passed to 
the routine to be included in the calculation. 

The first time scrcp is called for a given set of 
records, the cre variable must be set to zero to 


initialize the calculation. 
CRC calculated for the record. 


scrcep returns a 


On subsequent calls 


to scrcp, the cre variable must be set to the CRC 


previously returned. 
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For CRC generation, no additional processing is required 
to complete the CRC calculation. The CRC returned after 
processing the last record, is the final CRC for the 
record(s). 


To complete the calculation for a CRC check, either 
complete the calculation as above and compare the 
stored to calculated CRCs, or pass the old CRC into 
the calculation as part of the last record and check 


the calculated CRC for zero. 
KKKKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KK KK KKK KKK KK KK KK KK KKK KKK KKK KKK K / 


#define NULL (char *)0 


unsigned screp (buffer, count, crc) 
char *buffer; 
int count; 
unsigned crc; 


register int cre reg; 
register int code; 


The exclusive-or of the data byte and the upper byte 

of the CRC register is the bytewise intermediate remainder. 
The byte code is generated by subtracting overflow bits 
with an exclusive-or. The CRC register is shifted one 
byte to the left before the partial product is added. 


while (count--) { 


code = (crc reg >> 8) & OxFF; /* Bytewise Remainder */ 
code *= (*buffer++ & OXxFF); 


l 


code “= code >> 4; /* Byte Code */. 
cre reg <<= 8; P*® SHitt CRC. ty 
crc reg “= code; /* Add Partial Product */ 


code <<= 5; 
exc reg “= code; 
code <<= 7; 
Cre yFeg “=: cade? 
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If the returned CRC is to be appended to a record, 
the byte order should be set such that the upper 
byte is followed by the lower byte in the record. 


return cre reg; 
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The C/UNIX Job Market 


Mark Tokay 
NAYLAND ASSOCIATES 


1986 was a great year for the C programmer or software engineer and 1987-88 promises to be even better. 
Recently, we checked with some of our colleagues around the country to see what and where the hot spots were. 


We found a real need for individuals specializing in language tools, compiler design, real-time distributed soft- 
ware, and control networks. Whether it was Silicon Valley, New England, Raleigh/Durham, Cheny, Washington, or 
Etna, New Hampshire, there was electricity in the air. 


Many of the hiring managers we talked to are working on the next generation CAE/CAD parts libraries, 
simulation-based diagnostic and test generation tools and firmware. Other managers and project leaders were 
developing real-time systems, ROM-based and loadable diagnostics, or operational firmware for CPUs, memories 
and disk controllers. Several vendors were developing network monitors/processors for high-speed token ring net- 
works. Others indicated there was a lot of activity in the publishing industry. 


What we see for 1987 and beyond is mind-boggling. Demand is increasing for individuals with experience in 
communications, graphics and real-time control systems. One or more years of C utilizing microprocessors is your 
ticket to a solid future. Greatest demand will be in computer control systems, closely followed by a need for people 
with experience with PC-to-mainframe communications and LAN technology. 


If you expect top dollar your experience should be in one of the following areas: real-time control, operating 
systems, I/O drivers, compilers and interpreters, diagnostics and application software. A knowledge of graphics 
and/or artificial intelligence in voice and data communications will also be very useful. 


[Mark Tokay is a recruitment and placement consultant for Nayland Associates in Nebo, North Carolina. He has 
extensive experience in recruiting for the C/UNIX market.] 
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An Introduction to C++: 


Operator Overloading © 


R. B. Murray 
© 1986, AT&T 


C++ (designed by B. Stroustrup) is a superset of the C programming language that supports stronger type check- 
ing, data abstraction, and object-oriented programming, without sacrificing the efficiency of C. This article intro- 
duces the C++ features that support operator overloading. 


Adding New Meanings to Operators 


The C language includes a set of operators that are defined for some set of the built-in types of the language. 
For instance, the operator + is defined for any combination of integral, floating, and (at most one) pointer types. 


C++ allows us to extend the definitions of operators to apply to user-defined types. This feature, called operator 
overloading, lets us define a set of basic operations for user-defined types that are ‘‘called’’ by using the C operators 
rather than by making explicit function calls. For example, if we have a C++ class that implements complex 
numbers, and we have declared the + operator for two complex numbers, we can use that operator when adding two 
complex numbers: 


Complex: az by rc; \ 
ine ae) © Reda ais Oy 


The + operator is actually a function call; in effect, the code that is generated does this: 
a = operator+(b, c); 


The syntax for a declaration or definition of an overloaded operator is identical to the function definition or declara- 
tion syntax, except that the name of the function is the keyword operator followed by the actual operator being 
redefined. For example, the definition of class Complex, and the addition operator for two members of that class, 
might look like this: 
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Clearly the growing language of 
choice for applications that are fast, 
portable and efficient. All of 
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program. 
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Whether you’re developing applications 
for yourself or for thousands, you pay 
for db__VISTA or db__ QUERY only 
once. If you currently pay royalties to 
someone else for your hard work, isn’t 


it time you switched to royalty-free 
db_ VISTA? 
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Features 

¢ Multi-user support allows flexibility to run on 
local area networks 

¢ File structure is based on the B-tree indexing 
method 

¢ Transaction processing assures multi-user 
consistency 

¢ File locking support provides read and write 
locks 

¢ SQL-based db_ QUERY is linkable 

¢File transfer utilities included for ASCII, 
dBASE optional 

¢ Royalty-free run-time distribution 

¢ Source Code available 

¢ Data Definition Lanquage for specifying the 
content and organization of your files 

¢ Interactive database access utility 

¢ Database consistency check utility 


File Management Record 
and File Sizes 
¢ Maximum record length limited only by acces- 
sible RAM 
¢ Maximum records per file is 16,777,215 
¢ Maximum file size limited only by available disk 
storage 
¢ Maximum of 256 index and data files 
¢ Key length maximum 246 bytes 
¢ No limit on number of key fields per record 
¢No limit on maximum number of fields per 
record 


Operating System 
& Compiler Support 
¢Operating systems: MS-DOS, PC-DOS, 
UNIX, XENIX, UNOS, ULTRIX, Microport, 
VMS 
¢C compilers: Lattice, Microsoft, IBM, DeSmet, 
Aztec, Computer Innovations, Turbo C, XENIX 
and UNIX 


8. SQL-based db_QUERY 
Add our new C-linkable, SQL-based, 
ad hoc query and report-writing 
companion product to providea 
simple relational view of your 

db__ VISTA applications. Without 
compromising speed. 


9. Free tech support. 


60 days of free technical and application 
development support for every Raima 
product. Of course, extended support 
and training classes are also available 
at your place or ours. 


ile Manager 


10. Upward database 
compatibility 

Start out with file managementina 
single-user PC environment—then 
move up toa multi-user LAN ora VAX 
database application with millions of 
records. You'll still be using db__VISTA. 


That’s why so many C programmers 
are choosing db__ VISTA. 


‘But don’t just take our word 
for it. — 


“‘Raima’s customer support and documentation 
are excellent. Source code availability and 
royalty-free run-time is a big plus.” 
Dave Schmitt, President 
Lattice, Inc. 


“db__VISTA has proved to be an all-round high 
performer in terms of fast execution, flexibility and 
portability, and has undoubtedly saved us much 
time and development effort.” 
John Adelus, Hewlett-Packard 
Office Productivity Division 


30-day Money Back Guarantee! 
Try db__VISTA in your environment 
for 30 days and prove it to yourself. If 


not completely satisfied, return it fora 
full refund. 


Price Schedule 
db_VISTA db__QUERY 
OC Single user $ 195 $ 195 
C Single user w/Source $ 495 $ 495 
C Multi-user $ 495 $ 495 
LC] Multi-user w/Source $ 990 $ 990 
NEW: 
1) VAX Multi-user $ 990 $ 990 
XC VAX Multi-user w/Source $1980 $1980 
Order Now. 


Put db__VISTA to work in your 
application program. Ordering is 
easy—simply call toll-free. We'll answer 
your technical questions and get you 
started. Call today. 


Call Toll-Free Today! 
1 (800) db-RAIMA 
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class Complex { 
public: 
double real, imaginary; 
Complex( double r = 0.0, double im = 0.0 ) { 
real = rx; 
imaginary = im; 


ie 


Complex operator+( Complex op 1, Complex op 2 ) 
{ 
return Complex(op_1.real + op 2.real, 
op l.imaginary + op 2.imaginary) ; 


} 


The operator function looks like any other C++ function definition, except for the function name (operator+ in 
this example). The return type of operatort+ is the type of the result of the +; in this case, the + of two Com- 
plex values is also Complex. The operator function returns anew Complex number, which contains the com- 
plex sum of the arguments. 


This could also have been done by defining a function called add, and calling this function to do the addition. 


The use of overloaded operators simply provides a convenient shorthand for commonly used operations involving 
Class objects. It’s much easier (and clearer) to write 


Complex a, b, c, qd; 

Complex operator+ (Complex, Complex) ; 
Complex operator* (Complex, Complex) ; 
a De ea: 

than the alternative without overloaded operators: 
Complex a,b,c,d; 

Complex add(Complex, Complex) ; 
Complex multiply (Complex, Complex) ; 
a = add(b, multiply(c, d)); 

Some Rules to Keep in Mind 


The following operators can be overloaded: 


Unary operators 


++ -- ~ ! - + & * 

Binary operators 

xk / 2 re - << >> < <= 
> >= ae t= & 2 | && | | 
= % /= $= += -= >>= <<= &= 
fe St [] () 


Ternary operator 


es 
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At least one of the arguments to an overloaded operator must be a class object. This prevents us from changing 
the existing C semantics; we can not redefine the addition of two integers, for instance. The assignment operator is 
predefined to be a bit-wise copy for any class object. The unary & (address-of) operator is predefined to return the 
address of the class object it is applied to. However, these operators can be redefined. For instance, an application 
may use a system of pointers and reference counts to avoid copying a class object when it is assigned. Instead, the 
assignment would simply copy a pointer to the data and bump a reference count stored with the data. The data 
would only be copied if the pointer was later used to change the data. 


None of the other operators have predefined meanings when applied to class objects. If an operator is applied to 


a class object, and the C++ compiler can not find a definition of the operator that applies, the C++ compiler should 
print an error message. 


Operator Precedence Is As InC 


There is no way to change the precedence of an operator; the normal C precedence is always used. For example, 
in the code 


Complex a,b,c,d; 
SD oe ee ay 


The * (assuming that operator* (Complex, Complex) has been declared) is:done before the +. 


Other than what is stated above, there are no other assumptions made about the semantics of the operators. For 
instance, in C++ (unlike Ada), operator!= and operator== will not be inverses unless specifically defined 


as such. In fact, == need not be a comparison operator at all; it might print both operands and return the number of 
times the wind has shifted since last Tuesday! 
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¢ Define arbitrarily complex macros with #define command. 

e Include and nest files to any depth with #include command. 

© Include lines with #if, #ifdef and #ifndef commands. 

e Define multiple constants with #enum command. 

e Optional extra feature: Imbed formatting or other commands 
in your source code. (Lines starting with . or * are ignored.) 


Fast and flexible 

e 30 times faster than the Preprocessor published in Dr. Dobb’s 
Journal. 

¢ Can be used for any language, including assembler. 

¢ Can be used as a stand-alone macro/include processor. 

¢ Code can be used as the lexical analyzer for parsers or 
assemblers. 


ostetetetetete® 
00078 8r8recececeseseeeseeeststatettstatatatetaatatatatatattatatatatatatatetetetetitetetesetes 
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210 N. Bassett St., Room 104 

Madison, WI 53703 

Tele. (608) 258-7078 
TO ORDER: Specify both the operating system (MS-DOS, CP/M 80 or CPM 68k) 
and the disk format (8 inch CP/M or the exact type of 5% inch disk). Send a check or 
money order for $95 ($105 for foreign orders). Foreign checks must be denominated 


in U.S. dollars drawn on a U.S. bank. Sorry, | do NOT accept phone, credit card or 
COD orders. Please do NOT send purchase orders unless a check is included. 
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The fact that such ‘‘strange’’ definitions of == and != are legal doesn’t mean that they’re good practice, of 
course. It’s as important to choose the operators carefully in the same sense that it’s important to choose function 
names carefully. For instance, one should avoid situations where expressions such as 
(( a == b) && (a !=b )) 


can be true. The best course is to define one of these operators as the inverse of the other, e.g.: 


int operator!=(Complex a, Complex b) 


{ 

return. bias == b)s 
} 
Commutativity 


Commutativity is also not assumed. For instance, if you define the addition of an integer and a Complex like 
this: 


Complex operator+(int, Complex); 
5 So gia A 

Complex c,d; 

Pye vee as 


This is an error; while operator+(int, Complex) is declared, operator+(Complex, int) isnot. It’s 
easy to implement the other case, however: 


Complex operator+(Complex c, int 1) 
{ 


return i+ Cc; 


++ and -- 


The ++ and -- operators can be overloaded, but there is no way to distinguish between the prefix and postfix 
forms. For class objects, the two forms x++; and ++x; are synonymous. Also, ++x does not mean (x += 1) 
unless operator++ is so defined (which is probably a good practice). 


Overloaded operators can be used for more than just new types of numbers. For instance, one might have a class 
that represents a set of people.* The various C operators might be defined to implement the set logic. In the 
examples below, the actual implementations of the classes and functions are omitted for clarity: 


Class Set { /*...*/ }; 
class Person { /*...*/ }; 
Set operator+t=( Set, Person ); //Add a person to a set 
Person smith; 
set tax auditors; 
tax auditors += smith; //Adds.the person "smith" 
//to the set of tax auditors. 


* A better design would have sets of Objects, with a Person being derived from an Object. This would 


allow the set operations to be used for sets of other things. This approach requires the use of references, a C++ 
feature which will be covered in a subsequent article. 
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I chose operator+= instead of operator |= because the operation to add a person to a set has a natural 
inverse, the operation to remove a person from a set. + has an obvious inverse (-); the inverse of | is not a single 
C operator. 


You can overload each operator more than once; the argument types are used to determine the form of the opera- 
tor that is used (like any other overloaded function). For instance, we can also define the addition of a Set toa 
Set. 


Set operator+=(Set, Person); //Add a Person to a Set 
Set operatort+=(Set, Set); //Add a Set to a Set 
Set tax auditors, vampires; 


Person jones; : 
//Add "jones" to the set of tax auditors: 
tax auditors += jones; //Calls operator+=(Set,Person) 


//Add all tax auditors to the set of vampires: 
vampires += tax auditors; //Calls operatort+=(Set, Set) 


Other reasonable operators are listed below. However, choosing operators is a little like choosing function 
names; there may be other reasonable semantics for these operators: , 


Function Semantics 


Set operator+(Set, Person) Retums a new set which is the union 
of the argument Set and Person 


int operator==(Set, Set) Returns 1 iff the two sets are identical 


int operator<=(Set, Set) Returns 1 iff the first set is a subset 
of the second. 
int operator<(Set, Set) Retums 1 iff the first set is a proper. 


Set operator~ (Set) 


Person operator[] (Set, int) 


The last one is of particular interest. The binary operators [] and () can be overloaded like any other opera- 
tors. Given the above definition of operator [], the code 


Set tax auditors; 
Person third auditor = tax_auditors[3]; 


does the call: 


third auditor = operator[] ( tax auditors, 3); 


The “‘Because It is There’’ Syndrome 


There are programmers who will use a new feature simply because it exists. However, overloaded operators 
probably should not be used with every class type; not all types use operations that have obvious mappings to the C 
operators. A programmer who defines operator% (Widget, Widget) to set the color of the first Widget to 
the color of the second, and then only uses this operator once, has probably done more harm than good. Overloaded 
operators should be used only for fundamental operations that will be used often. 
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Summary 


Many applications use a set of objects, with a set of primitive operations on those objects. If (and only if) those 
Operations can be mapped logically to a set of C operators, the overloaded operators can be used to produce code 
that is shorter and clearer than code written using function calls. This is especially true for applications that use the 
output of one operation as the input for another; an expression using C operators is much easier to understand than 
an expression involving nested function calls. In C, we might have code like this: 


/* Find all tax auditors who are not vampires and work 
either on mondays or thursdays */ 


Set tax auditors, vampires, work _on_mondays, work_on_ thursdays; 


return (set intersect (tax_auditors, 
set intersect (set_inverse (vampires), 
set union(work_on_mondays, work_on_thursdays)))); 


In C++ this last statement is: 


return (tax_auditors & ~vampires 
& (work _on mondays | work_on _thursdays) ); 


In this way, overloaded operators provide a shorthand notation that can make code both shorter and easier to 


understand. 


[Rob Murray is a Member of Technical Staff in the Programming Language Development Department of AT&T in 
Summit, NJ. Mr. Murray’ s work interests include code selection and compiler technology.] 
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getdates() 


e Jun 2-5 ‘“‘Hands-On Program- 
ming in C’’ seminar in Washington 
D.C. sponsored by Integrated Com- 
puter Systems. (800) 421-8166. 


e Jun 8-12 USENIX Summer 
Conference and Exhibition in 
Phoenix, AZ. (213) 592-3243, 
Judith DesHarnais — conference 
coordinator. 


e Jun 8-12 ANSI X3J11 meeting in 
Paris, France (Host: COSMIC). 
This will be a joint meeting with 
the ISO C Standards Committee. 


e Jun 23-26 ‘‘Hands-On Program- 
ming in C’’ seminar in San Diego, 
CA sponsored by Integrated Com- 
puter Systems. (800) 421-8166. 


e Sep 14-18 ANSI X3J11 meeting 


in Framingham, MA (Host: Whi- 
tesmiths, Prime, and others). 


e Dec 7-11 DECUS US bi-annual 
Symposium in Anaheim, CA. (617) 
480-3259. 


¢ Jan 25-29 1988 ANSI X3J11 
meeting in Austin, TX (Host: 
Tymelabs). Note that this replaces 
the previously scheduled meeting in 
Phoenix, AZ in December, hosted 
by Motorola. The ANSI meeting 
schedule has been revised to 
accommodate the anticipated clos- 
ing dates of public review periods. 


e Feb 10-12 USENIX. Winter 
Conference and Uniforum in Dal- 
las, TX. (213) 592-3243, Judith 
DesHarmais — conference coordina- 
tor. 


oo 


Practical Yacc 
— Part 2 


Yacc is a tool that assists pro- 
grammers to develop language 
parsers for inclusion in their C pro- 
grams. First implemented on the 
UNIX operating system, it was 
ported to various DEC computers 
by DECUS members, and then 
extended by Scott Guthery to PC’s 
running DOS. Since source code is 
provided with his DOS version it 
could be adapted to other host 
environments as well. Part 1 of 
this series [in Volume 2 Number 4 
of The C Journal] reviewed the 
background, context, and sources 
for yacc. 


This installment reviews the 
basic steps in using yacc (in 
simplified form to preserve an 
overall perspective) and examines 
some additional reference sources 
beyond The UNIX Programming 
Environment by Kernighan and 
Pike. 


The Main Steps to Using 
yacc 


There are three basic steps in 
using yacc. The first step is to 


© Dennis Deloria 
MOBIUS Corporation 


develop a language specification file 
which defines the grammatical and 
lexical rules of your new language. 
This file also defines the actions to 
be carried out by the finished parser 
as each grammatical and lexical 
rule for your language is recognized 
in the input stream. The language 
specification file must follow the 
syntax conventions specified for 
yacc, and has C code intermixed 
with yacc code as _ appropriate. 
Language specification source code 
files typically have a .y extension, 
like the 


The second step is to submit 
your language specification file to 
the yacc program, which generates 
as output, a C source code file. 
This source code will implement a 
parser for your language and can be 
used either as a stand-alone pro- 
gram or incorporated as part of a 
larger program. 


A side benefit of the process of 
submitting your language 
Specification file to yacc is the 
assistance yacc provides for debug- 
ging your language specification. 


The power of command languages 
resides in their nearly infinite flexi- 
bility for combining language ele- 
ments into expressive, creative 
Statements; however, this same 
power can set traps for the novice 
language developer where unantici- 
pated grammatical combinations 
lead to incorrect or ambiguous 
action sequences. Yacc has the 
capability to provide high level 
debugging assistance at the earliest 
language development _ Stages, 
where the corrections are easiest to 
implement. 


The third and final step in using 
yacc is to compile and link the 
yacc-generated (and any of your 
own) code using your favorite C 
compiler and linker. If you wish, 
you can freely hack the yacc output 
before compiling it. Alternatively, 
you can add C code to the language 
specification file and resubmit it to 
yacc. I prefer the latter approach 
since the finite state machine gen- 
erated by yacc is cryptic at best, 
with its forbidding stack implemen- 
tation, symbol tables, and internal 
communication systems. 
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The Language 
Specification File 


A language specification file is 
divided into three parts, separated 
by double % characters as follows: 


declarations 
oo 

66 

rules 

o°0 

66 


programs 


Technically, the declarations 
and programs sections are optional, 
but in practice they are usually 
included. 


The declarations section 
includes all C language definitions 
and declarations that are intended to 
be global in scope (such as prepro- 
cessor macros, function declara- 
tions, typedefs, etc.) That is, 
variables defined in the declarations 


section are available to the actions 
in the rules section, as well as, to 
any functions included in the pro- 
grams __ section. Alternatively, 
definitions and declarations can be 
put*at the beginning of the rules 
section which limits their scope to 
the actions within the rules section, 
excluding access by any functions 
in the programs section. As a third 
option, definitions and declarations 
can be put at the beginning of the 
programs section or inside of the 
various functions placed there, as in 
conventional C programs. 


This flexibility is instructive in 
that it is typical of yacc, where any 
given task can _ optionally be 
assigned to quite different parts of 
the language specification file, 
depending on the language design 
and the outcome intended by the 
developer. To quote Johnson, the 
author of yacc, and Lesk, the author 


C CODE FOR THE PC 
source code, of course 
eee 


of lex (which is a companion pro- 
gram generator commonly used in 
conjunction with yacc) “‘this gives 
even the _ fussiest programmers 
enough rope to hang themselves.’’ 


The rules section is the heart of 
the language specification file, and 
is the place where the precise gram- 
matical rules are defined for your 
new language. Based on the gram- 
matical rules you provide, yacc will 
generate a parser that will recognize 
each instance of each rule encoun- 
tered in the input stream to your 
program. You can, and normally 
will, provide one or more actions to 
be carried out when any given 
grammatical rule is _ recognized. 
This collection of rules and actions 
can be arbitrarily complex, and is 
readily adaptable to a dizzying 
array of applications. We will 
shortly come back to an examina- 
tion of the rules section in more 
detail. 


BARTENDER 
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The programs section is the 
place where you can put as many C 
functions as you need to round out 
your finished application program. 
(Note that you may also put com- 
plete C functions in other source 
files and reference them at link-time 
— not all the source need be in the 
yacc input file.) In addition to any 
functions specific to your applica- 
tion program, there are two func- 
tions normally included to carry out 
some of the normal parser opera- 
tions: yylex, which gets tokens 
from the input stream to be passed 
to the parser for processing by your 
grammatical rules, and main, 
which is the same as main in any 
C program. main typically 
includes a call to yyparse, the 
parser function generated by yacc, 
and yyparse repeatedly calls 
yylex to get the tokens it needs. 
yylex can either be written by the 
user or can be generated using the 
program lex. 


Another function commonly 
included is yyerror, which pro- 
vides a means for incorporating 
error recovery procedures into your 
parser. 


It is necessary to have a means 
for the various parts of the parser to 
communicate with each other as 
they carry out their tasks. To facili- 
tate this a series of names for vari- 
ables and functions has been 
reserved for exclusive use by yacc 
in the finished parser. These names 
all start with yy, as in yylex, 
and yylval, a variable used to 
pass token values from yylex to 
yyparse. AS a consequence, you 
should avoid using variable or func- 
tion names that start with yy, 
unless, of course, you need to pro- 
vide functions expected by yacc, 
such as yylex. 


In addition to the prefix yy, 
two other symbols are reserved for 
use by yacc. One is the percent 
character, %, which is the escape 
character generally used in yacc 


Specifications. Another is the dollar 
sign, $, which is used to facilitate 
easy communication of variable 
values between developer-defined 
actions and the parser generated by 
yacc. 


Writing Rules and Actions 


As I mentioned above, the rules 
section is the heart of your 
language specification file. This is 
where you define to yacc what you 
want it to permit as a variable 
name, for example, or a command, 
or an arithmetic operation. 


The rules section is made up of 
one or more grammar rules. In its 
Simplest version a grammar rule has 
the form: 


name rule body ; 


Typically, a rule body will have 
multiple forms. For example, in 
the C language a variable name can 
be represented by a single alpha- 
betic character, either lower or 
upper case, or by an alphabetic 
character that is followed by a 
sequence of alphabetic characters, 
by a sequence of digits, or by a 
Sequence of intermixed alphabetic 
characters and digits. In addition, 
the underscore character is treated 


as a letter. This might be 
represented in a rule as follows: 


LETTER 

varname LETTER 
varname DIGIT 
varname UNDERSCORE 
UNDERSCORE varname 


varname 


In this example varname is 
defined to be a token of the type 
LETTER returned by yylex, ora 
varname followed by another 
token of the type LETTER, or a 
varname followed by a token of 
the type DIGIT, and so on. The 
name being defined is separated 
from the rules by a colon, and the 
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vertical bar character is taken to 
mean ‘‘OR’’. The completed rule 
body is terminated by a semicolon. 


(The rule can be written in free- 
format.) 


Any token types returned by 


yy.lex must be declared as such in 
the declarations section as follows: 


$token LETTER DIGIT UNDERSCORE 


The capitalized token names are 
replaced by integers starting at 257 
in the yacc output. The default 
token number for a literal character 
is its ASCII value. Although you 
can optionally assign token 
numbers arbitrarily, it is generally 
best to let yacc assign them 
automatically. 


This example is somewhat 
artificial in the sense that the 
definition of variable names might 
be better handled by the lexical 
analyzer yylex, rather than by the 
parser. This would be particularly 
true if the lex program was used to 
generate the lexical analyzer, since 
lex can be used to specify regular 
expressions that could easily define 
arbitrary variable names. 


This is another example of the 
flexibility typically provided by 
yacc, where you can decide the 
most appropriate place to carry out 
any given parsing rule. You can 
optionally include a given task in 
yyparse by placing it directly in 
an action, or in yylex, or in an 
independent function that you have 
written that is called either by an 
action in the rules section, or 
perhaps even called by main. 
You are only limited by your own 
creativity — and of course the 
usual programming considerations 
such as efficiency, maintainability, 
etc. 


Each grammatical rule in the 
rules section can have one or more 
actions associated with it, to be car- 
ried out by the parser when an 
instance of that particular rule is 
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encountered in the input stream. 
Actions are enclosed in braces, and 
with the exception of the value 
passing variable names, actions are 
coded using standard C syntax. As 
an example, let’s examine the rules 
and actions defining expr (an 
expression) from the first calculator 
example in Kermighan and Pike’s 
book: 


NUMBER 
expe 
expr !=" 


expr: 
| | 

| 

Pexpr ' *! 

| 

| 


expr 
expr 
expr 
expr 


Ee Bef 


Spry fs « 
‘(’ expr 


a, 


In its simplest form this rule 
States that an expression can just 
consist of a NUMBER, which is a 
basic token type returned by 
yylex. The action associated with 
this rule is to return the value of the 
number to the function calling 
yyparse. By convention, the 
value of the pseudo-variable $$ is 
returned to the calling program. 
The actions you define can set $$ 
to the appropriate value using regu- 
lar C statements. The variables 
$1, $2, etc., refer to the sequential 
individual elements in the rule that 
are separated by whitespace. The 
dollar sign symbol is used to signal 
the presence of variables passed 
between your C action statements 
and the parser, and constitute the 
only deviation from standard C syn- 
tax in your action’ statements. 
Literals in a rule, such as the arith- 
metic symbols +, -, *, and /, 
are enclosed in single quotes. In the 
action statements these are replaced 
by C operators, and do not require 
the single quotes. 


If you do not specify an action, 
the default action is to return the 
value of the first element in the rule 
asin { $$ = $1; }. Thus, the 
first action included above need not 
have been explicitly stated. 


{= Se was } 
(2: = ea oe} 
{oO Sub ee Chasen 
io So ee ee Baste} 
GS ec Se (Sarr 8 
Gerd 22 } 


Where To Next? 


The summary I have presented 
here is greatly simplified, and 
excludes much essential informa- 
tion in order to preserve an overall 
perspective of the operation of 
yacc. I encourage you to get more 
information directly from one or 
more of the following reference 
sources to assist you in preparing a 
yacc language specification file. 


The source I consider the most 
immediately useful is The UNIX 
Programming Environment, by 
Kernighan and Pike (Prentice-Hall, 
1984) which I discussed at length in 
Part 1 of this series. If you have 
not already done so, buy a copy and 
implement all six versions of hoc 
as your basic yacc tutorial. 


The next most useful reference 
is the yacc user’s manual included 
in the basic UNIX documentation 
set. This can be most easily found 
in Volume 2 of the UNIX 
Programmer's Manual (Holt, 
Rinehart and Winston, 1983 and 
earlier) which has been around for 
years. A new version of the UNIX 
Programmer’s Manual has recently 
been published, which documents 
UNIX System V. The yacc user’s 
manual can be found in Volume 5, 
titled Languages and Support Tools 


(Holt, Rinehart and Winston, 1986), 
of this new series of manuals. The 
yacc section is essentially the same 
as that appearing in the old Volume 
2, so there is no advantage to pur- 
chasing the new version if the old 
is availabie. 


Another excellent reference 
source is the 1978 article by John- 
son and Lesk, the authors of yacc 
and lex, respectively, _ titled 
Language Development Tools and 
published in the Bell System 
Technical Journal (Vol 57, No. 6, 
July-August 1978). If you have 
access to a good university com- 
puter library I highly recommend 
getting a copy of this article. 


The references I have cited so 
far have a decidedly practical orien- 
tation, but some of you may be 
interested in the theory behind 
LALR(1) parsers as represented by 
yacc. The best sources are Aho and 
Ullman, Principles of Compiler 
Design (Addison-Wesley, 1977), 
and Aho, Sethi, and Ullman, Com- 
pilers: Principles, Techniques, and 
Tools (Addison-Wesley, 1986). 


One other reference deserves 
mention as an intermediate source 
of information, halfway between 
the pragmatic user’s manuals and 
the theoretical compiler design 
books. This book is by Schreiner 
and Friedman, /ntroduction to Com- 
piler Construction with UNIX 
(Prentice-Hall, 1985). This book 
shows how to create a simplified C 
language compiler using yacc and 
lex, and in the process provides 
information that goes far beyond 
that provided in Kernighan and 
Pike and the UNIX Manuals. It is 
less accessible as an introductory 
reference, but once you have com- 
pleted the tutorial in Kernighan and 
Pike it is useful for answering some 
of the issues left unresolved there, 
and for many more advanced 
topics. If you decide to make yacc 
a regular part of your computer 
toolkit you will probably want to 


purchase this text. 


In the next part of this series we 
will discuss the specifications for a 
cross-reference utility which we 
will implement using yacc, and 
begin with the language 
specification file for a simplified 
version of it. 


[Dennis Deloria is a partner in 
MOBIUS Corporation in Northern 
Virginia. He writes on-line tele- 
phone interviewing systems in C, 
and custom database management 
systems for many applications in C 
and KMAN, all for personal com- 
puters.] 
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rray Names 
and 
Pointers 


Matt Bishop 
Research Institute for Advanced Computer Science 
NASA Ames Research Center 
Moffett Field, CA 94035 


Beginning C programmers are often told that an array name is a pointer. While true, this comparison is usually 
misunderstood, because array names cannot be manipulated in the same way pointers can. 


Recall that a pointer to a character is defined by char *pointer; and an array is defined by char 
arrayname [SIZE]; where SIZE is the number of elements in the array. The first declaration allocates space 
for the pointer, and none for storage; if declared as a global, the value contained in pointer: will be 0. The 
second declaration allocates SIZE characters for storage, and the name arrayname is the address of the zeroth 
element of that array. Note no storage is reserved for a pointer. This is the crux of the distinction: the name 
pointer contains the address of a character, and is a variable, whereas the name arrayname is itself the address 
of a character and is a constant, the value of the constant being determined at compile or run time (depending on 
how the compiler allocates storage.) So, a good rule of thumb is: an array name is a constant; a pointer is a variable. 


What this means is that pointer arithmetic may be performed on pointer, since the arithmetic changes the 
value stored in that location. But since the name arrayname is a constant, its value cannot be changed by pointer 
arithmetic (or any other kind of manipulation, for that matter.) This distinction is often skimmed over, and begin- 
ning C programmers usually discover this property by accident. 


It is time for some examples. First, we will look at a function to initialize a 4x1 matrix: 


O1 #* this is -part of a larger program™in file x.ci,..-*/ 
02 

03 float vector[4]; /* the matrix */ 
04 

05 vecinit () 

06 { 

07 

08 /* put 1.0 into each of the elements */ 
09 

10 *vector+t+ = 1.0; 

11 *vyector++ = 1.0; 

SBS) *vector++ = 1.0; 

13 *vector++ = 1.0; 

14 

1B /* now reset the value of "vector" 

16 *k* to what it was originally */ 

Bg 

18 vector -= 4; 

19 } 
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Notice that vector is declared as an array, with enough storage for 4 floating point numbers allocated. As we 
described above, the name vector refers to the address of the first element in the array, and so is a constant. But 
in lines 10 through 13, and again in line 18, this routine changes the value of vector by using pointer arithmetic! 
Hence, this part of the program will not even compile, and the resulting error messages are: 


c", line 10: illegal lhs of assignment operator 
ec", line 11: illegal lhs of assignment operator 
.c", line 12: illegal lhs of assignment operator 
Cv ¢ 
Cc 


line 13: illegal lhs of assignment operator 
", line 18: illegal lhs of assignment operator 


Let us change the routine slightly: 
O1 /* this is part of a larger program in file x.c... */ 
03 float vector [4]; /* the matrix */ 
05 vecinit () 
06 { 
07 float *v; /* used to load vector */ 
10 /* set v to point to the first element in vector */ 


a's v = vector; 


14 /* put 1.0 into each of the elements */ 


J 2 
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16 *yv++ = 1.0; 
ae | *yv++ = 1.0; 
18 *yv++ = 1.0; 
19 k*y = 1.0; 
20 } 


Now we use a pointer, v, to load the initial values into vector. The value of vector is never manipulated 
or changed; only the value of v is. Since v is a pointer, it is a variable, and this manipulation is legal. In fact, the 
program now compiles without errors. 


There is one exception to the ‘‘array name constant’’ rule: when an array is declared as a parameter in a function 
definition, in that specific case, it is identical to a pointer declaration. This seems like an annoying inconsistency, 
but in fact is not at all inconsistent. Recall that the compiler does not allocate storage for array parameters in func- 


tion definitions; instead, it allocates a pointer to the base of the array. Let’s look at a sample program to be more 
specific. 


Consider the following C function; it copies a string from its second argument to its first: 


01 /* strcopy.c */ 

02 

03 

04 /* copy the string in the array "from" to the array "to" */ 
05 

06 strcepy(to, from) 

07 char to[100]; /* copy to this string */ 
08 char from[100]; /* copy from this string */ 
09 { 

10 

Lt /* just copy until you hit the end */ 

12 

13 while ((*tot++ = *from+t+) != ’\0’); 

14 } 


Note the declarations of the parameters from and to; they are declared as arrays. However, only a pointer to 
each is allocated (and as you would expect, the pointers are named to and from, respectively.) In fact, unless 
your C compiler checks array bounds, it is customary to leave the size out of the declaration, so lines 7 and 8 would 
be written 


7 char to[]; /* copy to this string * / 
8 char from[]; /* copy from this string */ 


rather than as above. Now, since to and from are pointers to characters, they can be manipulated as pointers, and 
so the pointer arithmetic in line 13 is legitimate; compiling this function will produce no error messages. 

In practice, since to and from are being treated like pointers rather than array names, C programmers would 
be most likely to write the declarations to reflect this: 


7 char *to; /* copy to this string */ 
8 char *from; /* copy from this string */ 
However, this is a matter of taste, not a part of the language. 
It is very easy to confuse array names and pointers, and figuring out the difference is something many C pro- 
grammers have trouble doing. This article has tried to speed that process by explicitly describing the differences. 


[Matt Bishop is a Research Scientist at NASA's Research Institute for Advanced Computer Science. He special- 
izes in computer security and graphics.] 
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Doctor C’s Pointers 


by Rex Jaeschke 
© 1987, Rex Jaeschke. 
All rights reserved. 


The static Puzzle Revisited 


In The C Journal Volume 2 Number 1 issue, Puz- 
zle Comer contained the following problem. 


static structs { 


ant; 
Long. 13 
double d; 

Pood; 

ie 

{ 


struct s s2; 


‘‘The structure sl has class static but what about 
s2? Does it inherit the static class from the 
definition of the structure s? Show a simple way to 
prove your answer.’’ 


Well that puzzle generated a lot of mail and also a 
lot of erroneous responses, so much so that I want to 
cover this problem one more time in the hopes of put- 
ting it to rest for good. In doing so, I will reprint frag- 
ments of a letter showing ‘“‘conclusive’’ proof that, 
indeed, s2 does inherit the class static. This 
letter is fairly representative of-a number of others 
which also contained ‘“‘conclusive’’ proofs. However, 
before we look at the example cited, understand that 
the REAL answer is that s2 DOES NOT inherit the 
class, even though certain evidence can make it appear 
that way. 


‘‘The structure s2 declared in the function f () 
inherits the class static. This conclusion is sup- 
ported by the attached program which prints previ- 
ously assigned values of the structure members and 
assigns new values to the structure members between 
function calls. The previously assigned values are 
retained between calls proving that the attribute 
Static applies. This program has been executed on 
a SUN Microsystems system and on a Commodore 
Amiga using the Manx Aztec C68k compiler, with 
similar results.’’ 


The “Solution” 
#include <stdio.h> 
main () 
{ 

int.k: 


void. £4)> 


for (k = 1; k <= 5; £ (k++)) 


e 
tA 


[RKRKKKKKKKKKK KK KK / 


static struct s { 


tnt i: 
long 1; 
double d; 

} sl; 

void f(r) 

= Re) ap oe 


{ 
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struct s s2; r = 2, memloc = 773914656, s2 = 0 0 0.000000 
r = 2, memloc = 773914656, s2 = 2 20 200.000000 


printf("r = %d, memloc = %u, s2 = ", I, &S2); 
prints ( 3d Slid-ti\n", s2i4, 82.1, Se.) 7 r = 3, memloc = 773914656, s2 = 0 0 0.000000 
r = 3, memloc = 773914656, s2 = 3 30 300.000000 
s2.1 = x; 
s2.1 = (long) (10 * rx); 
s2.d = (double) (100.0 * r); r = 4, memloc = 773914656, s2 = 0O 0 0.000000 
r = 4, memloc = 773914656, s2 = 4 40 400.000000 
return; 
} r = 5, memloc = 773914656, s2 = 0 0 0.000000 


/*note that %u may need to be %lu on some systems*/ y = 5, memloc = 773914656, s2 = 5 50 500.000000 


iler A, : 
The Output produced by the reader’s compiler Case for the Prosecution 


was: 

r = 1, memloc = 146300, s2 = 0 65536 -—0.000000 Compilers A, B, and C do partially support the 
| xr = 2, memloc = 146300, s2 = 1 10 100.000000 readers’ claims. At the end of the first loop iteration 
b= > i ee = Ser i - ; = ES the structure members are initialized and at the begin- 
was , memloc = pel = : . : . "1: 
Bs. menioc = 146300,.62 2 4 20. 400. 000000 ning of the next iteration these values are still intact. 


With Compiler D the member values are partly intact 
except that the double value is zeroed out 


The output produced by my compiler B, was: somehow. With the interpreter E, the values are 


r = 1, memloc = 2772, s2 = 5493 65604 0.000000 definitely not retained; they are zeroed each time the 
r = 2, memloc = 2772, s2 = 1 10 100.000000 function starts up. The second output from the inter- 
r = 3, memloc = 2772, s2 = 2 20 200.000000 preter contains a printf statement just after the 
r= 4, memloc = 2772, s2 = 3 30 300.000000 structure members are assigned to to indicate that they 
r = 5, memloc = 2772, s2 = 4 40 400.000000 


were indeed set to the appropriate values, but those 


values were not retained across the subsequent call. 
The output produced by my compiler C, was: 


All translators are correct in that they produce 


r = 1, memloc = 65500, s2 = -20 213782737 0.000000 appropriate results. You know the old saying ‘‘garbage 
r = 2, memloc = 65500, s2 = 1 10 100.000000 in, garbage out’’, well that’s what we get here. Dif- 
oh . by yet = 65500; = x : = nh a bie ferent translators had different garbage go in, so dif- 
r , memloc = 65500, s2 = ‘ 

De pelo 6 6ERGO. ene A 40 dO. O00 ferent garbage came out, but they all had garbage. 


While it may seem that the structure members retained 
their value across function calls, that is not, in fact, the 
case. Because of implementation approaches, several 
| memloc = 4050, s2 = 4072 270928983 0.000000 translators just happen to make it appear they have 
, memloc = 4050, s2 1 10 0.000000 retained their value. 

memloc = 4050, s2 2 20 0.000000 


The output produced by my compiler D, was: 


KR RAR RK 
Il 
OP WD FP 


2 oe Ll WASh ae en SED BOOOND The first proof that s2 is definitely NOT static 

je memloc = 4050, s2 = 4 40 0.000000 is the initial display of its contents. All four compilers 

produce at least one non-zero value for the three 

members. According to K&R page 198, section 8.6, 

ete output produced By Re eer ae ‘*Static and external variables which are not [expli- 

r = 1, memloc = 774635544, s2 = 0 0 0.000000 citly] initialized are guaranteed to start off as zero; 

r = 2, memloc = 774635544, s2 = 0 0 0.000000 automatic and register variables which are not [expli- 

r = 3, memloc = 774635544, s2 = 0 0 0.000000 citly] initialized are guaranteed to start off as gar- 

ee ee 4 een Be eae ee bage.’’ Therefore, if s2 were indeed of class 

ee ee static, each of its members would contain the 

default initial value of zero cast to their particular 

The output produced by my interpreter E, with type. Clearly, this is not the case, so IS NOT 

apa ilees static but then why are the values “‘retained’’ in 
r = 1, memloc = 773914656, s2 = 0 0 0.000000 some cases? — 


r= 1, memloc = 773914656, s2 


1 10 100.000000 
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On machines with a stack architecture, the stack is 
used for function argument passing and for storing 
auto variables. Clearly, if s2 is not of class 
static, it must be of class auto, since it is inside 
a function definition and it is not class register. 
In the simple looping program used above, it is very 
likely that the stack frame set up by the first iteration 
of the loop will be in exactly the same place on the 
stack for each of the iterations. In fact, this is sub- 
stantiated by all examples since each shows the 
address of s2 to be the same in each iteration (for a 
particular translator). 


Now as an auto variable is ‘‘released’’ when a 
function terminates, its value typically remains intact 
on the stack, but that part of the stack is freed-up for 
other use by the compiler-generated code. If that part 
of the stack is not used for anything else in the mean- 
time, then when the function is called the next time, 
the space allocated on the stack for the automatic vari- 
ables will be EXACTLY the same range of addresses 
as were allocated in the previous iteration. And since 
automatic values are typically not initialized by an 
implementation, by default, the initial values of s2’s 
members are thé same as it had the previous time. 


Note that this is only true for the compilers A, B, 
and C. Compiler D must have generated code that 
somehow used that part of the stack previously con- 
taining s2.d, in between calls. In the case of the 
interpreter, it appears to initialize all automatics to 
zero. This latter case is perhaps unfortunate since if 
that is what it really does, then sooner or later some 
programmer will begin to rely on that property. In any 
case, such behavior is UNDEFINED according to the 
proposed ANSI Standard and it can be very unwise to 
rely on undefined behavior. 


How then could you prove this fact, as required by 
the puzzle? Well the first set of non-zero display 
values proves it but if you want further proof, call one 
or more other functions from within the for loop 
such that function f is not called each time in succes- 
sion. Make sure that each other function called allo- 
cates 10-20 bytes of automatic space and explicitly 
initializes it to some completely different value, such 
as “‘all zeros’’. That is, cause the residual values of 
the automatic structure members to be overwritten by 
something else between calls to function f. 


[Rex Jaeschke is Co-founder and Editor of The C 
Journal, and an independent consultant and lecturer. 
He is a member of the X3J11 ANSI Standards Com- 
mittee for C and is a Contributing Editor for The 
DEC Professional and The Programmer’s Journal. ] 


co 


Are You Missing Back Issues? 


The first two issues of The C Journal are sold out! 
You can still purchase individual copies of Volume 1 
(Numbers 3 and 4) and Volume 2 (Numbers 1, 2 and 
3) at $6.95 plus 1.50 postage and handling ($8.45 total 
for U.S. and Canada only) each. Outside the U.S., 
payment must be in U.S. dollars drawn on a U.S. bank. 
Airmail shipping/handling costs are $3.00 to Europe 
and $4.00 to Asia. Sorry, we cannot bill you for back 
issues. Please send a check, money order, or 
MasterCard/VISA information (card number and 


expiration date) to Back Issues, The C Journal, PO 
Box 220, Rescue, CA 95672. 


Volume 1 Number 3 contained reviews of two competing 

EMACS editors, several IBM PC function libraries, and 
development packages. As part of our regular features we 
had an interview with Ron Cain (the developer of Small-C), 
an article on UNIX environment variables, a feature on the C 
pre-processor, and a look at some common programming 
errors. 


Volume 1 Number 4 focused on several aspects of portabil- 
ity problems. Articles covered efficiency, economics, and I/O 
considerations, the goals of the ANSI X3J11 committee, and 
an interview with Jim Brodie of Motorola, the founder of 
X3J11. Case studies included porting compilers from the 
VAX to 68000, and from the IBM PC to the IBM 370. 


Volume 2 Number 1 covered efficiency, Data Hiding in C++, 
VAX VMS I/O implementation, side effects of expression 
evaluation, C compilers for mainframes, and the importance 
of scope to C programmers. The interview was with Tom 
Plum of Plum-Hall. 


Volume 2 Number 2 covered debugging with the use of 
Static analysis tools and a case study of debugging large pro- 
gramming projects. Other articles covered object-oriented 
programming in C++, syntax-directed editors, C and RISC 
architectures, and a comparison of C and Pascal. The 
SPOT_LIGHT interview was with Tom Pennello and Frank 
DeRemer of Metaware. 


Volume 2 Number 3 was our special ANSI C issue. Articles 
included a list of ANSI reserved words and identifiers, a 
description of the ANSI certification procedure, function proto- 
types, hosted program startup and termination, the ANSI 
preprocessor, pointers, floating-point arithmetic, trigraphs, 
and discussions of the meaning of ANSI to optimizers and 
UNIX users. SPOT_LIGHT was on Larry Rosler of AT&T. If 
you plan to write ANSI-conforming C programs (or any C pro- 
grams in the next five years) we highly recommend you hold 
onto this issue! 


lf you’re really desperate for an article from our first two 
issues we can provide you with a photocopy of that article. 
The cost is $2.50 an article (includes postage and handling). 
lf you are interested, send us a note to the above address 
and we will send you a photocopy of the Table of Contents of 
the first two issues. Sorry, but we cannot photocopy an entire 
issue! 
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Brian W. Kernighan was an 
under-graduate at the University of 


Toronto in Engineering Physics 
graduating in 1964. He then went 
to graduate school at Princeton, in 
the Electrical Engineering Depart- 
ment. Upon graduating in 1969, he 
joined the staff of the prestigious 
Bell Labs Computing Science 
Research Center, where he has 
been employed ever since. 


The C Journal: The Bell Labs 
Computing Science Research 
Center seems to provide an unusual 
working environment. Just how 
does it operate and what is your 
charter? 


Brian Kernighan: The charter is 
to do interesting research in com- 
puting science. There are 50-60 
people, all selecting their own pro- 
jects and doing what they think is 
interesting. The typical style of 
work is individual or very small 
groups, two or three people at most. 
Most people work on one or two 
projects with a couple of other peo- 
ple and maybe something on their 
own as well. A lot of the ideas that 
have come out of here reflect that 
Style. People don’t propose pro- 
jects — you just do it and there is 
no managing except what you do 
yourself. We don’t have much of 
an infra-structure of support people, 
we don’t have people to program 
for uS or very many to build 
hardware for us. However, we do 
have superb people to look after our 
machines. 
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SPOT LIGHT 


Brian W. Kernighan 


CJ: Is there some formal process 
for budgeting? 


Kernighan: Yes, but it is invisible 
to most of the people who are actu- 
ally doing honest work, that is, 
non-management. Money is avail- 
able for projects fairly freely: if 
somebody wants to spend money 
on something, the more money that 
they want to spend the more appro- 
val that it actually requires. The 
approval is based on how much 
money there is available and what 
other projects people want to do 
and also the track record of the per- 
son involved. 


CJ: What is the nature of your 
more recent research? 


Kernighan: In recent years I have 
been interested in what I call little 
languages: languages that are 
focused on some narrower domain 
than general purpose languages 
such as C. Languages for docu- 
ment preparation and graphics, for 
example. 


I spent a lot of time last year on a 
language for specifying linear pro- 
gramming models. Jon Bentley and 
I have been working on a language 
for algorithm animation and Jon, I 
and a chemist named Lynn Jelinski 
have been working on a language to 
describe chemical structure 
diagrams. Peter Weinberger, Al 
Aho and I have been working on 
awk, off and on, and we have 
almost completed a book on it. 


CJ: You wrote The Elements of 
Programming Style with P.J. 
Plauger in 1974 and revised it in 
1978. It’s interesting to go back 
and review that book in the light of 
C’s popularity. Since C lends itself 
to writing cryptic code can you 
comment on how C fits into that 
book’s framework. 


Kernighan: The genesis of that 
book was, in fact, horrible exam- 
ples in Fortran, a language which 
does not encourage style and does 
not provide much of a mechanism 
for writing clear code. C on the 
other hand provides a mechanism 
sO you can write nice, clean code. 
When I write C I try to make it rea- 
sonably clear. At least the language 
gives you the option of writing rela- 
tively clear code — you don’t have 
to worry about card-image formats, 
column 72 — that kind of thing. C 
is free-format. 


Unfortunately, C gives you an 
incredible number of ways to hang 
yourself and to write absolutely 
impenetrable code. With pointers 
and combinations of operators with 
side-effects, for example, you can 
create a rat’s nest. I guess there are 
people who do that because they 
think it is fun or because they don’t 
know any better. 


You can write well or badly in 
any language — some just make it 
easier or harder to write good code. 
C makes it comparatively easy to 
write good code. 


CJ: You mentioned earlier that 
your perspective on C is entirely 
from within Bell Labs. 


Kernighan: It’s clear that I sit in a 
rather specialized corner. I learned 
C from Dennis Ritchie and Ken 
Thompson and their code was very 
good. Those guys know what they 
are doing. Fortunately, I grew up 
with people who were concerned 
about writing good code. If I were 
learning some other language and 


You can write well or 
badly in any language. 
C makes it compara- 
tively easy to write good 
code. 


didn’t have that kind of people 
around me to set a good example, it 
might be harder to write good code. 


CJ: Could you comment on case- 
sensitivity in languages. This is 
claimed to be both a strength and 
weakness of C and of course the 
Pascal folks have their own casing 
conventions which they bring to C - 
using leading upper-case letters, for 
example. 


Kernighan: There is no problem 
having a leading upper-case letter 
Or, in fact, interior upper-case 
letters in variable names. They can 
certainly make the name clearer. In 
Pascal, it’s hard to keep variable 
names localized so you must use 
long names to keep them unique 
and mixed casing makes that easier. 


We certainly use mixed case 
effectively in written English. The 
lack of case-sensitivity eliminates 
useful distinctions such as differ- 
ences between variable and macro 
names. In the old days terminals 
and machines often couldn’t handle 
both cases. Since most modem 
machines and terminals can now 


distinguish both cases, that capabil- 
ity ought not to be thrown away. 


CJ: In 1976, again with Plauger, 
you wrote Software Tools. At that 
time C’s use was still not wide- 
spread. The syntax of Ratfor, while 
like that of C, was not quite C. 
Was there a conscious effort to 
present, in Ratfor, a manageable 
subset of C? 


Kernighan: Yes, Ratfor was a 
conscious attempt to steal as much 
of C’s syntax as possible while at 
the same time making it look some- 
what like FORTRAN. After all, 
Ratfor was a preprocessor that gen- 
erated FORTRAN, so the more 
FORTRAN-like Ratfor was, the 
easier it was to _— generate 
FORTRAN and also the easier it 
was to get people to use it. 


CJ: You used the IBM-style NOT 


symbol instead of C’s exclamation 
mark. Why? 


Kernighan: There was a 
difference between what we actu- 
ally used ourselves and _ what 
appeared in the book. Basically, 
that was a typographical problem. 
The dominant machine at that time 
was the IBM-360, so we went with 
IBM’s representation in the typeset- 
ting. But in our programs we used 
the C operators. 


CJ: I assume that you used «& and 
| instead of && and ||, respec- 
tively, to simplify matters. 


Kernighan: Yes, that made one 
less obstacle for the FORTRAN 
programmer. 


CJ: Was Ratfor’s design a joint 
effort by yourself and Plauger? 
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Kernighan: No, Ratfor was my 
design. We started the book while 
he was still at Bell Labs. We 
finished it after he had gone to 
work for Yourdon, Inc. 


CJ: With the advent of Fortran-77 
(and Fortran-8X) does Ratfor have 
a future? 


Kernighan: Yes. Fortran-77 did 
not really solve the control flow and 
cosmetic problems inherent in For- 
tran. Ratfor is probably just as 
relevant now as it ever was. 


Ratfor is probably just 
as relevant now as it 
ever was. 


CJ: On page 318 of Software 
Tools you state the following: ‘‘We 
think that the appearance of a 
language is also important, but that 
puts us in a minority.’’ What do 
you mean by appearance and are 
you still in a minority? 


Kernighan: At the time, the world 
was still heavily into upper-case- 
only keypunches, and card-oriented 
languages like Fortran and Cobol. 
Just from a visual standpoint, an 
unindented, upper-case program is 
hard to read, and thus hard to work 
with. We believed strongly that 
lower-case, indented code, not 
confined to columns 7 to 72, was a 
lot easier to read. We also believed 
that judicious use of operators like 
> instead of Fortran’s .GT. made 
programs easier to read. 


I don’t know whether we’re still 
a minority, but as older languages 
are less used and terminals get 
better, readable programs will 
become the norm rather than the 
exception. 


CJ: Is programming an art or sci- 
ence? 
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Kernighan: While it is probably 
more an art we now understand 
many more aspects of program- 
ming. And we can get more of 
them. right the first time or at least 
quicker than, say, ten years ago. 
The other aspect is that there are a 
lot more programming tools around 
now — more sophisticated com- 
pilers, for example, and programs 
like lint, yacc and lex, that 
make part of the job more 
scientific. And we continue to 
make progress in that area. 


CJ: One thing I see contributing to 
programming being an art is that I 
can buy a reasonably powerful 
development system for a couple 
thousand dollars and set up shop as 
a software vendor. Yet the lack of 
a business plan, organization and 
economic factors make _ design, 
quality assurance, and software 
engineering impossible or at least 
highly unlikely. 


Kernighan: I associate software 
engineering with very large projects 
— Bell Labs switching systems, for 
example — with lots and lots and 
lots of people. Now if you are an 
individual entrepreneur you don’t 
have time for all that, particularly if 
you want to eat next week. Such 
formal procedures don’t make any 
sense for small projects. While 
some formal structure is necessary a 
lot of it can be a hindrance. 


CJ: In 1981 you did a Pascal ver- 
sion of the popular Software Tools 
book and that reflected Pascal’s 
favored position at that time. Is it 
likely we will see a C version of 
the book? 


Kernighan: Bill [Plauger] and I 
have talked about it sporadically for 
some years and we even got to the 
point of writing a couple of draft 
chapters. Bill is very busy right 
now and I don’t know if such a 
book will ever be produced. In 


hindsight, we probably should have 
done a C version at the same time 
as the Pascal one. The world has 
moved on since then and a lot of 
sophisticated, useful and_ better 
tools have become available. 


CJ: 1978 saw the release of The C 
Programming Language, _ affec- 
tionately referred to as K&R. 
Could you elaborate on the reason 
for this book. Was it a formal col- 
lection of the various internal docu- 
ments and papers published in the 
Bell Labs Technical Journal? 


Kernighan: My recollection was 
that initially I wrote a tutorial on B 
and once Dennis did C, I wrote a 
tutorial on C which was circulated 
inside the Labs. The tutorial was 
fairly popular but really wasn’t ade- 
quate so I decided to do a full-scale 
book. My tutorial became Chapter 
1 and Dennis’s reference manual 
became Appendix A. 


CJ: Can we expect to see a revised 
version? 


Kernighan: Dennis and I are talk- 
ing about it. The probability is 
very high that there will be a 
second edition. 


The probability is very 
high that there will be a 
second edition [of K&R] 


I’m really uncomfortable with 
fat books that describe small 
languages — a 500 page book on 
Basic, for example. So I don’t 
want to produce a C book that is 
Substantially bigger than the one we 
have now. I have not yet decided 
on a precise treatment of the ANSI 
Standard, in particular, how to 
address the large library. I’m reluc- 
tant to double the size of the book 
to include the whole library. And 


I’m not sure how many typical 
readers are going to be deeply 
interested in the details of the Stan- 
dard that are aimed at compiler 
writers. 


CJ: I’ve had a copy of The UNIX 
Programming Environment you 
wrote with Rob Pike, and a version 
of yacc for a year to two, and 
recently I rediscovered them both. 
I found Chapter 8, on Program 
Development, to be a gold mine, 
and despite the UNIX title, this 
chapter is sufficient justification for 
non-UNIX people to buy the book. 
The clear, concise introduction to 
“‘practical yaccing’’ can help the 
reader solve a whole class of every 
day problems. As you correctly 
stated, we invent far more 
languages than we realize. 


Kernighan: That chapter was 
meant not so much to emphasize 
the notion of languages as it was to 
get across the utility of yacc, in 
particular, and to a lesser extent that 
of make and lex. The particular 
language we implemented, hoc, 
was rather a boring language. 


CJ: After a few hours of looking 
at the book I threw together a gram- 
mar for an elementary C expression 
processor that was immediately use- 
ful for seminars and in teaching C. 
It has most of the operators, a full 
math library and a help and symbol 
table dump facility. I see yacc as 
a very valuable tool once somebody 
recognizes that they are designing a 
language. The fact that someone 
could fairly easily write a cross 
reference utility or something that 
would beautify code that under- 
stands the language’s grammar is 
very useful. 


On behalf of the user commun- 
ity I would certainly like to thank 
you very much for doing that “*bor- 
ing’’ language because it has 
become the ‘‘every man’s’’ guide 
tO yacc. 


CJ: We have touched on a couple 
of aspects of the ANSI Standard. 
Have you been following it closely? 


Kernighan: I have not been track- 
ing the Standard carefully. I have 
read various abbreviated reports, 
such as those Tom Plum has writ- 
ten for The C Journal, and have 
found those quite useful. The Stan- 
dard has done a couple of really 
Significant things and then a large 
number of improvements that are of 
considerable help to compiler wnit- 
ers but of less direct utility to the 
programming public. 


Function prototypes look like a 
really good deal, something that 
would have been nice to have had 
in C all along. In my forays into 
C++ that is the single aspect of it 
that first comes to mind, a real step 
forward because it prevents you 
from making all sorts of classic C 
mistakes. 


Portability is turning out 
to be one of the main 
assets that C provides 


The second aspect that is very 
valuable is formalizing the libraries 
so that you know the properties of 
all the string functions, and of 
scanf and printf, and so on. 
Not that they are part of the 
language in the sense that they are 
wired in and compilers know about 
their properties, but this is the 
library you should expect to find if 
you run C programs. That is 
another step to assuring portability 
and portability is turning out to be 
one of the main assets that C pro- 
vides. C is actually a more portable 
language than some others that sup- 
posedly are standard and portable. 


CJ: What about the impact on 
existing code? For example, assign- 
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ing a pointer to an int is now a 
Syntax error unless an explicit cast 
is used. 


Kernighan: Again having grown 
up in a protected environment 
makes my view of the language 
perhaps different than other 
people’s. Our compilers for a long 
time now have complained when 
you play too fast and loose with 
pointers and pointer to integer 
conversion, at least the explicit ones 
that happen all in a single file. If I 
try to say pointer = mal- 
loc() I will get a complaint, so I 
go in and add a cast, usually ahead 
of time without waiting for the 
compiler to complain. 


Now I know that other com- 
pilers in some sense inherit the ori- 
ginal and quite loose definition but 
solid compilers, certainly good 
commercial ones, probably reflect 
this better practice anyway and the 
Steps that the Standard takes to say 
that’s the way it ought to be are 
genuine contributions as well. 


CJ: Off-line, you touched on the 
idea of having some control of your 
Own typesetting capability and I can 
certainly relate to that. I don’t 
know if you were a pioneer in that 
area but it would seem that there 
was a trend that began, certainly 
with your style, where authors 


began to typeset their own works.: 


And it became OK to have a good 
deal of white space at the end of a 
page to ensure examples and figures 
didn’t span pages. 


Kernighan: Well, we wanted to 
have control of the typesetting but 
that was because we had a 
typesetter; that made it feasible. 
Without the typesetter we may not 
have thought of it that way. Also, a 
variety of people here at the Labs 
had experience in building for- 
matters — probably half a dozen 
right here in this center — Doug 
McIlroy, Joe Ossanna, Ken, Dennis 
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and myself had done formatters. 
So we had the notion that it was 
quite plausible to do interesting 
tasks with text formatters. We had 
the typesetter because Ossanna had 
been very interested in having such 
a facility available, and so it was a 
natural extension to try to typeset a 
book. 


The other aspect is that when 
Bill and I were collecting ammuni- 
tion for the Elements of Program- 
ming Style, it became perfectly 
clear that for a large number of the 
bad examples the person who had 
written them was the victim of his 
typographer; he may have provided 
a correct program but by the time it 
went through the typesetting pro- 
cess it had been mangled and we 
wanted to avoid that. 


It is clear to me that C++ 
is a reasonable follow- 
on to Cin many 
respects 


Then the page layout problem 
that follows is simply that a prop- 
erly indented program can some- 
times be hard to follow if it is split 
across a page boundary. So we 
tried to minimize the number of 
page breaks. Sometimes you can do 
that by rearrangements or by rewrit- 
ing the text, but sometimes you just 
can’t do a damn thing about it 
unless you have the programs in 
figures, but then you have to read 
the document with one finger here 
and one finger there. 


CJ: Are you surprised at the popu- 
larity of C? 


Kernighan: It is not surprising 
now but it was. There are a couple 
of reasons why both C and UNIX 
are popular. One is that intrinsi- 
cally both C and UNIX are really 


nice, they are both well done, and 
they genuinely do a job better than 
any of the comparable tools would 
do. 


The other is that they have been 
very fortunate in coming along just 
at the nght time. It’s a bit like 
Surfing: if you just get that wave 
then you can ride the wave for a 
very long distance. UNIX was for- 
tunate to coincide with the PDP-11, 
a very nice computer. The cost of a 
PDP-11 was quite modest. $50,000 
was the sort of money an individual 
part of an organization could afford. 
It freed them from the local com- 
puter center and that meant that all 
kinds of people could go off and 
experiment with this new operating 
system called UNIX. 


C rode that popularity because 
that was what you used when you 
ran UNIX on a PDP-11, and later 
on, a VAX. Then the other wave, 
that built on this popularity, was 
the personal computer machines 
(PCs and other 16-bit processors). 
Here was enough horse-power to do 
something useful. C turns out to be 
a good language for those machines 
and so is now riding into all kinds 
of non-UNIX environments. 


Furthermore, we have cross- 
fertilization. Good ideas from 
UNIX are finding their way into 
those other systems as well — the 
notion of a shell is now taken for 
granted in MS-DOS — and the 
Standard library, which is now part 
of the ANSI Standard, makes UNIX 
practice the way you use C in any 
environment. 


CJ: Any interesting languages on 
the horizon or other tools that have 
taken your fancy? 


Kernighan: One interesting topic 
is ‘‘What is the next C?’’ I don’t 
know what the next C is but it is 
Clear to me that C++ is a reasonable 
follow-on to C in many respects. 
Every language has its domain of 


applicability, how big a program 
and what kind of program can you 
reasonably write with it, and so 
forth. C covers a fairly large spec- 
trum of activities. But it is clear 
that for some tasks C is not quite 
up to the job. Very large programs 
is one area where it intrinsically 
doesn’t provide enough facilities. 


C++ is not a finished 
product but it is quite a 
reasonable model for 
where C might go in the 
future 


You don’t have the ability to ade- 
quately localize the scope of objects 
and code, to build fire walls so that 
if you and I are writing a program 
together we can do our own thing 
without clobbering each other. For 
this, you need something like 
ADA’s package. 


SAPIENS V8 


What C++ does in addition to 
providing an early experiment with 
function prototypes is to give you a 
mechanism by which you can build 
in those fire walls — the data hid- 
ing capabilities of C++ are quite 
nice. Then in addition you can take 
the new objects that you have built 
and wrap them up and get at them 
with standard C operators. For 
example, for complex number arith- 
metic you can use the + and * for 
addition and multiplication of com- 
plex numbers even though what 
you are manipulating are not stan- 
dard integers. 


Now C++ is not a finished pro- 
duct but it is quite a reasonable 
model for where C might go in the 
future. It is arguably already as 
useful as ADA® and certainly more 
useful than Modula-2. Also, a sub- 
stantial advantage over other 
languages, in particular over ADA, 
is that you don’t have to learn a 
new language to start to use it 


because it really is compatible with 
C. So you can back into it and start 
by using function prototypes and 
better type checking and better error 
messages and gradually move into 
more sophisticated use of data 
abstraction. That is certainly what I 
have been doing with it. 


[C++] is arguably as 
useful as ADA and cer- 
tainly more useful than 
Modula-2. 


CJ: Thank you for your very valu- 
able time. 


UNIX jis a registered trademark of 
AT&T. 

PDP and VAX are registered trade- 
marks of Digital Equipment Corp. 
Ada is a registered trademark of the 
United States Government — Ada 
Joint Program Office 
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ar Circle 154 on Reader Service Card = 


CCsh transforms programs written in the Bourne shell into 
working C language source code that can be directly com- 
piled into an executable file using a machine’s native C 
compiler. 


Look at the powerful features CCsh provides you: 

- Creates C code that has good structure and style. There- 
fore it is readable, maintainable, and portable. 

- Invokes your native C compiler producing an a.out pro- 
gram up to ten times faster than the shell script. 

- Increases security in terms of source code protection and 
use of the setu/d bit. 

- Enhances performance through fast C code and use of 
the “sticky bit”. 

- Allows shell programmers to become more productive by 
having the broadened capability of using C version of pro- 
duction and prototype shell code without having to learn 
any new skills. 


CCsh is available on various machines starting at $375. 
Source code prices are available. We can be reached at 
718-849-2355 if you have any questions. 


We offer a FREE hotline, and a 15-day unconditional 
refund policy. We will never sell a copy-protected disk. No 
shipping, handling or hidden costs. 


Comeau 
Computing 


91-34 120th Street 
Richmond Hill, NY 11418 
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Notes on the Draft C 
Standard 


Reviewed by Rex Jaeschke 


by Thomas Plum 

Plum Hall, Inc. 

1987 92 pages 

ISBN 0-911537-06-6 
Price: $10 ($5 in quantity) 


This book is hot off the press 
and the reason I put it on the top of 
the ‘“‘books to review’’ in-tray is 
that it is the first text dedicated to 
the proposed ANSI C Language 
Standard — a topic of hot debate in 
recent months. To quote the pre- 
face, ““This book provides an over- 
view of the new draft Standard for 
C, for programmers, managers, or 
project leaders. It presents informa- 
tion that will soon become relevant 
to every programmer working in 
Sates 


This book is for people who 
already know C (and K&R) and 
want to know what is new about 
Standard C. If you have been fol- 
lowing Tom’s column in The C 
Journal you will have seen some 
of this material. The book also con- 
tains information previously pub- 
lished in other places. It is not just 
a reprint, however. It has been 
Significantly expanded and updated 
to reflect recent committee deci- 
sions. The six chapters are entitled: 
Overview; Comparisons with Ear- 
lier C; Prototypes; Expressions and 
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& Things 


Grouping; Efficiency in ANSI C; 
and Internationalization. 


Since Tom is Vice-Chair of the 
ANSI C Committee and the elder 
statesman of C authors, few are 
better qualified than he to address 
this important topic. I recommend 
you add this text to your set of core 
C references. 


A C Reference Manual 
Reviewed by Rex Jaeschke 


SECOND EDITION 

by Samuel P. Harbison 

and Guy L. Steele 
Prentice-Hall, Inc. 

1987 400 pages 

ISBN 0-13-109810-1 

ISBN 0-13-109802-0 (pbk.) 


I reviewed the first edition in 
The C Journal Volume 1 Number 
1 and raved about it then. The 
second edition contains a new 
chapter on the proposed ANSI C 
Standard and numerous standard- 
related comments throughout. Sim- 
ply stated, it is by far the most 
comprehensive C_ reference text 
available. Buy one and put it right 
there, alongside your copy of K&R. 


Three DOS-specific 
Texts 


Complete C Language 
Programming for the IBM 
PC 


Reviewed by Rex Jaeschke 


by Douglas A. Troy 

Little, Brown and Company 
1986, 500 pages 

ISBN 0-316-85311-9 
$16.95 


The stated goals of the book 
are: to teach and demonstrate C in 
real, practical applications; provide 
a book that can be used as a refer- 
ence once the basics have been 
mastered; and to help get the most 
from your IBM-PC. 


There are three main sections: 
Introduction; Basic language and 
library material (to be read in 
Sequence); and Advanced topics 
(read at random). The chapters 
include coverage of: Programming 
on the IBM-PC; Introduction to C; 
Structure and construction of a C 
program; Data types and data struc- 
tures; The preprocessor; C state- 
ments; Expressions and operators; 
Pointers; I/O and the standard 
library; Interfacing with assembler; 
Creating and using libraries; 
Advanced data manipulation; and 
Debugging. 


Two complete programs are 
developed piece by piece to illus- 
trate each new topic as it is intro- 
duced. The applications are a stock 
portfolio system and a calculator 
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THE PROGRAMMERS SHOP 


helps save time, money and cut frustrations. Compare, evaluate, and find products. 


RECENT DISCOVERY 


Periscope III - debugger with 64K 
protected RAM and breakout switch; 
breakpoints for hardware, memory, 
port, data. Real-time trace buffer, 
pass counter. PC $ 829 


Al-Expert System Dev't 


Arity Combination Package = PC $ 979 
System - use with C MS $ 229 
SQL Dev’t Package MS $ 229 

Auto-Intelligence PC $ 739 

Experteach - Powerful, samples PC $ 339 

Exsys PC $ 309 
Runtime System PC $ 469 

Insight 2+ MS $ 379 

Intelligence/Compiler PC. $739 

Tle PC Easy PC $ 435 


Personal Consultant Plus PC $2589 
Personal Consultant Runtime PC $ 85 
Turbo Expert-Startup(400 rules) PC $ 129 
Corporate (4000 rules) PC $ 359 


Al-Lisp 


Microsoft MuLisp 85 MS $ 159 
PC Scheme LISP - by TI os BD 
Star Sapphire MS $ 459 
TransLISP - learn fast MS $ 89 
TransLISP PLUS 
Optional Unlimited Runtime $ 139 
PLUS for MSDOS $ 179 


Others: IQ LISP ($239), IQC LISP ($269) 


Al-Prolog 
APT - Active Prolog Tutor - build 
applications interactively PC $ 49 
ARITY Prolog - full, 4 Meg 

Interpreter - debug, C, ASM PC $ 229 
COMPILER/Interpreter-EXE PC $ 569 
Standard Prolog MS $ 77 
MacProlog Complete MAC $ 269 
MicroProlog - Prof. Entry Level MS $ 85 
MicroProlog Prof. Comp./Interp. MS $ 439 
MPROLOG P550 PC $ 175 
Prolog-86 - Learn Fast MS $ 89 
Prolog-86 Plus - Develop MS $ 229 
TURBO PROLOG by Borland PC $ 69 


BAS_C - economy MS $ 179 
BAS_PAS - economy MS $ 135 
Basic Development System PC $ 105 
Basic Development Tools PC $ 89 
Basic Windows by Syscom PG 295 
BetterBASIC PC $ 129 
Exim Toolkit - full ha Sas eet 
Finally - by Komputerwerks PC $ 85 
Inside Track ’ PCS * 400 
Mach 2 by MicroHelp PC 3S 
Peeks n Pokes PE-3: 39 
QuickBASIC PC $ 69 
Stay-Res PCS. 75 
$ 


Turbo BASIC - by Borland PC 


FEATURE 

NET-TOOLS - Access NETBIOS- 
compatible network systems from 
Microsoft C, Pascal, FORTRAN, 
Assembler, Lattice C. Full Source. 
No Royalties PC $129 
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FREE Newsletter 


Insightful commentary, guest columnists, survey 
results, and valuable resource listings. Interviews, 
technical articles, predictions — even cartoons. No 
wonder 96% of our readers pass The Programmer's 
Letter on to their friends; no wonder 72% make sure 
they get their copy back to keep for reference! You 
can request a FREE sample copy today by calling 


our toll-free number. A personal subscription is just 
$25 per year. 


Our Services: 
* Programmer’s Referral List * Dealers Inquire 
* Compare Products * Newsletter 
* Help find a Publisher * Rush Order 
+ Evaluation Literature FREE * Over 700 products 
* BBS-7PMto7 AM 617-740-2611 + National Accounts Center 


C Language-Compilers 
AZTEC C86 - Commercial 
C86 PLUS - by Cl MS $379 


Datalight C - fast compile, good code, 
4 models, Lattice compatible, Lib 


source. Dev’rs Kit PC bed 
Datalight Optimum - C MS $109 
with Light Tools by Blaise PC $168 
Lattice C - from Lattice MS $269 
Let’s C Combo Pack PC $ 99 
Let’s C PC $ 59 


Microsoft C 4.0- Codeview MS $275 
Rex - C/86 by Systems & 
Software - standalone ROM MS $695 


Turbo C by Borland PC $ 69 
Uniware 68000/10/20 Cross 

Compiler MS Call 
Wizard C MS $299 


Rom Development Package 


C Language-interpreters 


C-terp by Gimpel - full K & R MS $219 
C Trainer - by Catalytix PC $ 89 
INSTANT C - Source debug, 

Edit to Run-3 seconds, .OBJs MS $369 
Interactive C by IMPACC Assoc. PC $209 
Run/C Professional MS $155 
Run/C Lite MS $ 79 


C Libraries-General 


Blackstar C Function Library PC $ 79 
C Essentials - 200 functions PE-3 75 
C Function Library MS $109 
C Tools Plus (1 & 2) - Blaise PC $125 
C Utilities by Essential PC $129 


C Worthy Library - Complete, machine 


independent MS $249 
Entelekon C Function Library PC $119 
Entelekon Superfonts for C PC $ 45 


Greenleaf Functions-portable, ASM $139 
LIGHT TOOLS by Blaise PC $ 69 


Atari ST & Amiga 


We carry full lines of Manx, Lattice, & 
Metacomco. 


Call for a catalog, literature and solid value 


S(0-421-8006 


THE PROGRAMMER’S SHOP “ 


Your complete source for software. services and answers 


5-E Pond Park Road, Hingham, MA 02043 
Mass: 800-442-8070 or 617-740-2510 5/87 


RECENT DISCOVERY 
CxPERT - Expert systems 
shell, translates to C code to 
integrate with your application. 
Certainty factors, explanations, 
inheritance, frames, help MS $269 


dBASE Language 


Clipper compiler RC: :-Call 
dBASE II MS $329 
dBase III Plus PC $429 
dBASE III LanPack PC $649 


DBXL Interpreter by Word Tech PC $139 
FoxBASE+ - single user 
Quick Silver by Word Tech 


PC $439 


dBASE Support 

dBase Tools for C PC". 65 
dBriet with Brief PC Call 
DBC ISAM by Lattice MS Call 
dBx Translator to C MS $319 
dFlow - flowchart, xref MS. Call 


Documentor - dFlow superset MS Call 
Genifer by Bytel-code generator MS $299 


QuickCode III Plus MS $239 
Fortran & Supporting 

50:More FORTRAN PC $ 99 
ACS Time Series MS $399 
Forlib+ by Alpha MS $ 59 
MS Fortran - 4.0, full °77 MS $279 


No Limit - Fortran Scientific PC $115 
PC-Fortran Tools - xref, pprint PC $165 
RM/Fortran MS Call 


BTRIEVE ISAM MS $185 
BTRIEVE/N-multiuser MS $455 
Flash-Up Windows PCxd: 79 
GSS Graphics Dev’t Toolkit PC $375 
HALO Graphics PC $205 
Development Package MS $389 


Informix 4GL-application builder PC $789 
Informix SQL - ANSI standard PC $639 
Opt Tech Sort - sort, merge MS $119 


PANEL MS $215 
Pfinish - by Phoenix MS $229 
PolyLibrarian by Polytron MS $ 79 


PolyBoost - speed I/O, keyboard PC $ 69 
PVCS Corporate-source control MS $309 


PVCS Personal MS $109 
QMake by Quilt Co. MS $ 79 
Report Option - For Xtrieve MS $109 
Screen Machine PC.Si59 
Screen Sculptor PES 95 
SRMS - source control MS $107 
Synergy-create user interfaces MS $375 
VXM - multi-env. link MS $175 


Xtrieve - organize database MS $199 
ZAP Communications - VT 100 PC $ 89 


FEATURE 


UI Programmer - Quickly generate 
dBASE User Interfaces, prototypes. 
Use supplied templates or create own. 
Pop-up help, bounce bar menus, screen 
forms. II, II], FoxBASE+ , Quicksilver, 
Clipper. PC $249 


Note: All prices subject to change without notice. 
Mention this ad. Some prices are specials. Ask about 
COD and POs. Formats: 3” laptop now available, plus 200 others. 
UPS surface shipping add $3/item. 


that evaluates arithmetic expres- 
sions. 


The book is well laid out with 
plenty of graphics and program 
examples. Despite the fact that the 
examples are photo-reduced copies 
of dot matrix printout, the programs 
are easy to follow since they are 
well documented and formatted. A 
wall chart diagramming C’s syntax 
is included. A reasonable stand- 
alone text. 


C Development Tools for 
the IBM PC 


Reviewed by Rex Jaeschke 


by Al Stevens 
1986 Brady, 240 pages 
ISBN 0-89303-612-9 


This book has reusable C 
language software tools that directly 
support the development of on-line, 
interactive software systems. The 
tools are developed to run on an 
IBM PC, XT or AT. The tools 
include routines for file manage- 
ment, indexed access methods using 
B-trees, menu management, screen 
display, and sorting. All source 
code is listed and was developed 
for use in numerous commercial 
applications and is available on 
diskette from the author for $25. 


The chapters cover such topics 
as: Software development philoso- 
phy; C development tools; 
Terminal-dependent functions; 
Cache memory routines; Data file 
and menu management; Screen gen- 
eration; Sorting; and B-tree index 
creation. 


All code is adequately docu- 
mented and well laid out. However, 
it is reproduced from dot matrix 
printout and often exceeds the text 
margins. A different font is used for 
small, in-line program examples — 
it is bold and larger than that of the 
narrative. This type is also used for 
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function name subheaders which, 
for some reason, are often enclosed 
in boxes. Despite the inconsistent 
choice of typefaces the author does 
a good job at presenting the useful 
tools listed above. 


Crafting C Tools for the 
IBM PCs 


Reviewed by Rex Jaeschke 


by Joe Campbell 
1986, Prentice-Hall 
ISBN 0-13-188418-2 
434 pages 


This book is very Intel and 
DOS-specific. It assumes you know 
your way around C and want to get 
at some system specifics. Topics 
covered include: C and the Intel 
8088; An overview of PC-DOS; C 
on DOS; Disk directory manipula- 
tions; Keyboard and standard input; 
Standard output and the screen; 
Direct video access; Advanced 
video topics; Interrupts; Serial com- 
munications; and comments about 
specific DOS C compilers. 


While a working knowledge of 
Intel assembler is not necessary to 
benefit from this book, it will help 
to exploit it to the fullest since 
numerous assembler examples are 
included. Specific details of the 
heap, the stack and the various 
memory models are presented. 


The author’s address and net- 
work addresses are listed and 
readers are encouraged to contact 
him with comments and questions. 
Source code is available on diskette 
at a cost of $25. A solid book for 
the serious DOS-specific C  pro- 
grammer who wants or needs to 
dabble in assembler. 


The Winner? 


While all three books are tar- 
geted at the IBM-PC market they 
don’t really overlap in content. 


Troy teaches by using applications 
examples, Stevens builds general- 
purpose development tools, and 
Campbell aims at the serious low- 
level DOS-user. Each has its place. 


New Arrivals 


e Data Handling Utilities in C, by 
Robert A. Radcliffe and Thomas J. 
Raab. Sybex, 1986, 520 pages, 
ISBN 0-89588-304-X, $19.95. This 
large tome covers data entry and 
data validation techniques in detail. 
And it does this with large amounts 
of code examples as well as discus- 
sion. Significant treatment is given 
to error handling. Has a slight DOS 
bias. All source code (plus more) is 
available on DOS diskettes. Practi- 
cal. 


e The C Companion, by Allen 
Holub. Prentice-Hall, 1987, 285 
pages. ISBN 0-13-109786-5. Pro- 
vides background material useful 
for mastering C and for understand- 
ing books such as K&R. Topics 
include: the compiler and develop- 
ment utilities; binary arithmetic; 
assembly language; code genera- 
tion; structured programming; 
pointers; recursion and compiler 
design; and debugging. Well writ- 
ten and useful. Holub is the C 
columnist for Dr. Dobb’s Journal; I 
recommend you read his monthly 
column. 


Order Let’s C Now 
by Rex Jaeschke 


a A Self-Teaching Guide to C Language 
in Two Volumes 


Volume 1: Introductory material 
13 User-friendly chapters 
A guide to learning C 


Volume 2: Advanced instruction 
13 self-teaching chapters 
All you need to know to use C 


26 lessons from DEC PROFESSIONAL magazine’s 
“Let’s C Now” column, updated and compiled by 
author Rex Jaeschke. Written for any operating system 
using DEC hardware, primarily for VAX and PDP. 


Plus: Tested examples 
Chapter summaries 
Glossary 
Author’s hints and suggestions 
Workbook format 


$22.95 each or save and order the set for only $42.95. 
Complete and return the order form below. 


Please complete and return with payment to: 


PROFESSIONAL PRESS, INC., P.O. Box 503, Spring House, PA 19477-0503 


Please send me: 


two-volume set(s) of Let’s C Now at $42.95 plus $3.00 (Canada $6.00) for postage and handling per set. 
copy(ies) of Let’s C Now, Volume 7 at $22.95 plus $1.50 (Canada $3.00) for postage and handling per copy. 
copy(ies) of Let’s C Now, Volume 2 at $22.95 plus $1.50 (Canada $3.00) for postage and handling per copy. 


Please charge my credit card: L) VISA CJ MasterCard Name/Title 


Company 
PICCQUIN FF toh hh a Se A I 

Address 
Fapiration: Date 223 ct ee fe ee City State Zip 
Signature 235 Country Telephone ( ) 
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Puzzle Corner 


The New Puzzle 


While the new puzzle is not as big or complicated as the last one, nonetheless, it does require some thought, and 
probably a bit of coding to test your ideas. 


What is the meaning of the following definition? 


static char (*b) [6]; 


This definition occurs within a function. To save you some time, I’ll tell you that b IS NOT an array of 6 
pointers to char. For that to be true, the definition would have to be static char *b[6]; and the two are 
NOT the same. Happy puzzling. 


The Previous Puzzle 


In case you actually worked on the monstrosity presented last issue, here is a more readable (?) version. This is 
output from a preprocessor with generous amounts of white space added. 


main () 
{ 
Chew cette i ie oO ee ee CE ee) 
me: Gl Wee, Aes oP oe Wena ae ON eee, -oaee  apee , <en s e G, aras e B  D 


me tie £1) Meee eS) Jo ee 
P(E So TE eee TL. ee Ay) ees 


(VOtG) Swern th eS Oo Ge GS AUS SNe Or.) aye A as ? —1 
Pon Cpt gehvord). writeti, "\bN) .fansrened) (1) yh sa ==) 


(void) write(l, " ", (unsigned) (1))-; 
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if (3) 


(void) write(1, "\n", (unsigned) (1)); 


eee 


ift. pe read (0,60007 9% 7G << IS<< Oe 60d) th eee 
Pet) Ge << 2 G1 ee 999 4 
goto ; 


Note how the following two statements are reduced. 


onat. 5 = Oy. < ee Ties Satna to ee eee ee CL oe Ty 
+ (t= = 1))} + (1 << (1 << 1 << EY )) ] 2 
becomes ; 
SO ee ng ee ee ees LO 
and 
Gis tic mt eters A Le GS eee b) kere <1 ¥)) 
+. (i So (1? << €1 <<e1)}). = 1: 
becomes 
= 80 - 1; 


Since these are compile-time constant expressions, you may want to look at the code your compiler Senta to 
see how good it is at recognizing such expressions. 


George E. Defenbaugh Jr, of Tulsa, OK gave it a shot and came up with the following (correct) discussion. 
‘‘This is an excellent example of what the preprocessor can (but probably should not be requested to) do. A simple 
solution is to dump the preprocessor output to a file and transform the names composed of mere underscores into 
something meaningful. The program reads a string of input of 80 characters or less. The number 80 is developed in 
an interesting manner, and reminds me of techniques used in assembler to avoid multiplication by performing multi- 
ple shifts. After the string is printed, a number of backspaces are performed equal to the length of the string. Then a 
space is printed, which yields the effect of having the string ‘move’ in an animated fashion. Then the string is 
printed again. This happens until the length of the buffer has been crossed, then a new-line is printed. As usual, this 
puzzle was fun and informative. I am going to give it to my C class.”’ 


Please submit puzzles and solutions to the Editorial address: The C Journal, Puzzle Comer, 1810 Michael 
Faraday Drive, Suite 101, Reston, VA 22090. 


oo 


GOING IN CIRCLES? 


Use the postpaid Reader Service Card bound into this issue to request free infor- 
mation from our advertisers. Just circle the appropriate numbers and drop it in the 
mail. 
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Products and Services 


Sapiens Sofware has a virtual 
memory manager for C programs 
running under DOS. It provides 
between 1 and 8 MB of virtual 
workspace. It runs on 8086, 80286 
and 80386 machines and does not 
require any hardware add-ons. You 
need only 256K of actual RAM. It 
currently supports compilers from 
Microsoft, Lattice and Aztec. $300. 


Sapiens Software Corporation 
P.O. Box 7720 

Santa Cruz, CA 95061-7720 
(408) 458-1990 


wr Circle Reader Service 170 = 


Convex has a vectorizing C 
compiler for UNIX systems. It 
includes 64-bit signed and unsigned 
integer types, specified as long 
long int. long long int 
constants are supported as are I/O 
format specifiers and appropriate 
casts giving high-speed access to 
Convex’ 64-bit 
capabilities. 


Convex Computer Corporation 
701 N. Plano Road 
Richardson, TX 75081 

(214) 952-0200 
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BAS _C is a source code con- 


verter that transforms BASICA 
source into C on DOS. It also 


accepts related BASIC dialects and. 


as well as converting the code, it 
"transforms spaghetti code into 
structured code during the conver- 
sion." The converted programs are 
scoped, indented and structured in a 
top-down fashion. 


Gotoless Conversion 
P.O. Box 50068 
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hardware 


Denton, TX 76206 
(214) 221-0383 
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HIGH SCREEN is a user inter- 
face development tool for use with 
C (and other languages, including 
dBASE MIII+) on  DOS-based 
machines. It includes screen genera- 
tion, help and. window manage- 
ment, automatic field checking and 
menu management. $129. 


Softway, Inc. 

500 Sutter Street 

Suite 222 

San Francisco, CA 94102 
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Crules is a library of functions 


which add rule-processing to C on 
DOS systems. Crules is written in 


Clisp, a library of tools which adds 


the symbolic capabilities.of LISP to 
a C environment. Crules is the first 
in a series of add-on products 
designed to place the functional 
power of AI in the hands of main- 
stream programmers. Clisp $189, 
Crules $79, both $240, manuals 
only $20. Supports Microsoft, Lat- 
tice and DeSmet compilers. 


Drasch Computer Software 
RFD #1 Box 202 

Ashford, CT 06278 

(203) 429-3817 
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Frank Fedele’s troops have 
released the Essential Communica- 
tions Library which contains a 
series of functions for manipulating 
the RS232 ports on a DOS system. 
BreakOut is a data line monitor that 
can monitor hardware and software 


communication problems. 
BreakOut $125, Comm _ library 
$185, both $250. Supports all the 
major compilers and has a 30-day 
money-back guarantee. 


Essential Software, Inc. 
274 Charlton Avenue 
South Orange, NJ 07079 
(201) 762-6965 
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TransLISP PLUS isa 
COMMON LISP interface to 
Microsoft C that offers portability 
and an extensive development 
environment with over 400 
COMMON LISP primitives. It 
offers "a practical approach to using 
AI." TransLISP $95, TransLISP 
PLUS $195. Requires a PC with 
320K and a floppy. 30-day money- 
back guarantee. 


Solution Systems 

335 Washington Street 
Norwell, MA 02061 
(800) 821-2492 

(617) 659-1571 
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Lattice has released a DOS C 
cross-compiler for the Apollo 
DOMAIN series 3000 workstations. 
Lattice also has cross-compilers for 
DEC, SUN and IBM systems, and 
DOS-to-Amiga and DOS-to-Atari 
ST systems. Apollo system $500, 
30-day money-back guarantee. The 
PLINK86 cross-linker is $495. 


Lattice, Inc. 

P.O. Box 3072 

Glen Ellyn, IL 60138 
(312) 858-7950 
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MISSING? 


_ If the Reader Service Card is missing from this 
issue Of The C Journal, please use the form below 
to request additional information on products or ser- 

_ vices mentioned in this issue. By circling the 
appropriate answers to the questions, you will help 
us speed your requests, as well as help our 
advertisers learn more about you, our readers. 


CIRCLE THE NUMBERS BELOW that correspond 
to the Reader Service numbers of the products 
you're interested in. Please allow several weeks for 
processing. 


100 101 102 103 104 105 106 107 108 109 
110 111 112 113 114 115 116 117 118 119 
120 121 122 123 124 125 126 127 128 129 
130 131 132 133 134 135 136 137 138 139 
140 141 142 143 144 145 146 147 148 149 
150 151 152 153 154 155 156 157 158 159 
160 161 162 163 164 165 166 167 168 169 
170 171 172 173 174 175 176 177 178 179 
180 181 182 183 184 185 186 187 188 189 
190 191 192 193 194 195 196 197 198 199 


Name 
Title 
Company 
Address 
City 
: State Zip 
Please circle all answers that apply to you: 


1. Do you 

a. Program in C as a job 

b. Manage C programmers 

c. Dabble in the basement 

d. Not currently working with C 


2. Your years of experience with C 
a. less than 1 c. 3-5 
b. 1-3 d. Old timer 


3. Operating system(s) you use regularly 
a. UNIX/XENIX 

b. MS/PC-DOS 

c. CP/M 

d. Macintosh 

e. Other 


4. Do you recommend/purchase C develop- 
ment tools? 
a. yes b. no 


5. Are you concerned about optimization/code 
generation quality? 
a. yes b. no 


Send to: 

The C Journal 
PO Box 2226 
Clinton, [A 52735 


This form expires on Jul. 31, 1987 (V3N1) 
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unsigned notes; 


Borland announced Turbo C 
and by the time you read this it 
should be shipping. To assist with 
this project, Borland acquired Bob 
Jervis’ company Wizard Systems 
Software (which accounts for their 
recent move to California.) Bob is 
the author of the Wizard C com- 
piler and Pre-C, a version of 
lint for DOS...SAS Institute has 
acquired Lattice, Inc. so that SAS 
has more control of its own 
development tools. (SAS’ 370-class 
C compiler is a port of Lattice’s 
DOS compiler.) Lattice will con- 
tinue to operate as a separate entity 
although all compiler development 
will move to Cary, NC under the 
capable hands of Oliver Bradley 
(SAS’ ANSI C representative). As 
a result, Steve Hersee, co-founder 
and VP of Lattice has ‘‘retired’’ to 
spend some of his hard-earned cash. 
P.J. Plauger, founder and 
President of Whitesmiths and 
ANSI C Secretary replaces Steve 
Hersee as the ANSI C representa- 
tive to ISO. 


Need a C text, or perhaps some 
other advanced computer book? 
Then call Dan Doernberg’s book- 
store in California, Computer 
Literacy Bookshop (408) 730- 
9955. They have a_ bimonthly 
newsletter which contains reviews 
and other useful information. A 
recent issue contained an interview 
with Ken Thompson of Bell Labs. 
They also promise prompt delivery 
via UPS...The next ANSI C meet- 
ing in Paris (France, that is) should 
be an interesting one given the 
expected attendance of representa- 
tives of C Standards groups from 
Europe and the Far East. Expect to 
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by Rex Jaeschke 


see some sort of multi-byte charac- 
ter support hooks in the final stan- 
dard for the Asian and Arabic 
languages. 


Scott Guthery of The Austin 
Code Works (512) 258-0785 has 
large memory model versions of his 
popular DOS tools yacc and 
lex. At $35 each, they are a 
steal...Aspen Scientific is shipping 
a version of the Curses window 
development package for DOS. 
Cost — $89 or $289 for source. 
They claim the package is compati- 
ble with UNIX System V 
curses. Supports Microsoft, Lat- 
tice, C86 and DeSmet compilers. 
Also EGA and MS-Windows. (303) 
423-8088. 


According to an independent 
DEC publication, C rates a 13% 
slice of the VAX programmer 
market, along with BASIC. 
COBOL rated 14% and, you 
guessed it, FORTRAN raced in 
with 45%. For the VAX engineer- 
ing community, C was second to 
FORTRAN...The Wang Institute 
of Graduate Studies (Tyngsboro, 
MA) has published a lengthy paper 
on C Grammars. Coordinated by 
Dr. Bill McKeeman, the study 
identifies 12 grammars for C and 
includes a lex and yacc gram- 
mar for the proposed ANSI C Stan- 
dard. The report ID is Technical 
Report TR-87-02 and is available 
from the Institute.Expect some new 
players to have compiler test suites 
for the proposed ANSI Standard. 
For now though, the main players 
are still Plum Hall and MetaWare. 


Rational Systems has released 
Version 2.2 of their popular 
Instant-C interpreter for DOS. It 


can use 640K+, has several new 
commands and a new manual. After 
using one of their earlier versions 
several years ago I put it aside. 
However, I recently upgraded to the 
new release and am using it in a 
project. I have a DEC VT220 
hooked to my PC via a comm port 
and I’m running Instant-C and load- 
ing comm .OBJ modules I 
extracted from Lattice’s C-food 
Smorgasbord library. I am doing 
this so I can debug C code that uses 
the many and varied terminal I/O 
escape sequences of the VWT220 
from C in an interpretive environ- 
ment without actually using a DEC 
machine (even though that is the 
final target). For certain projects, 
the ability to load object code into 
the interpreter is extremely useful. 


Sofcraft, Inc’s access method 
Btrieve seems to be getting even 
better. If you are serious about an 
access method with logical transac- 
tion backup and recovery, either 
stand-alone or in a network, check 
it out. Their documentation has 
always been superb. (512) 346- 
8380...Need a hot Ccross- 
development system for embedded 
M680x0 applications hosted on 
your VAX or PC/AT. Then check 
out the development system from 
Sierra Systems (415) 339-8200. 
They claim it outruns Greenhill’s 
system and can download code via 
a parallel link at super speeds, 
significantly reducing the wait time 
during testing. The cc driver is 
based on the UNIX driver and has a 
command script mechanism like 
Whitesmiths V3 compilers, in 
which commonly used compile/link 
switch combinations can be placed 
in prototype files. 


co 


Whitesmiths, Ltd. Has 
For over eight years The Compiler You Want display, a powerful 


Whitesmiths has multi-segment linker 


focused its efforts . Y f ting ROM- 
focused its etfors On ‘The Machine You Use. %2222™: 


and supporting a ability to display high- 
family of quality systems software. Today, Whitesmiths is level source code, assembly language, and machine object 
the only company offering compatible C and Pascal native code on one listing. 

and cross compilers for the full spectrum of computers on With Version 3.0, you get features supporting the emerging 
the market—from the IBM PC to the IBM 370, from the ANSI C standard, plus a uniform run-time environment and 
DEC Micro-11 to the VAX 8600, and all of the most identical source code across all machine architectures. 


popular processors in between. 

Version 3.0 of Whitesmiths compilers is now 
available, with new features and functionality 
designed to meet the needs of today's 
professional software developers. Features 


The Version 3.0 Pascal compiler provides you 
with a Pascal to C Translator, a full ISO Level 1 
implementation that includes conformant array 
parameters and numerous extensions. 

If you're in the market for C or Pascal, call 
include a C source level Whitesmiths at 1-800-225-1030. 
interactive debugger with We have the compiler you want 


breakpointing and variable Whit e smiths, Lt d. for your machine. 


59 Power Road, Westford, MA 01886 ® (617) 692-7800 / Telex 750246 


INTERNATIONAL DISTRIBUTORS: AUSTRALIA, Whitesmiths Australia, P.O. Box 21, 51 Grantham Street, Carlton, NSW 2218, (612) 588-7652 e FRANCE, COSMIC 
S.A.R.L., 52 Quai des Carrieres, 94220 Charenton Le Pont, Paris, (14) 378-8357 e GERMANY, GEl, Gesellschaft fuer Elektronische, Informationsverarbeitung MBH, 
Pascalstrasse 14, D-5100 Aachen, 02408/13-0 ¢ JAPAN, Advanced Data Controls Corp., Nihon Seimei Otsuka Bldg., #13-4, Kita Otsuka 1-Chome, Toshima-ku, Tokyo 
170, (03) 576-5351 ¢ SWEDEN, Unisoft AB, Fiskhamnsgatan 10, S-41455 Goteborg, (31) 125810 ¢ SWITZERLAND, RETIS, Realtime Software AG, CH-5001 Aarau, 
Bahnhofstrasse 96, (64) 247777 ¢ UNITED KINGDOM, Real Time Systems Ltd., P.O. Box 70, Douglas, Isle of Man, (624) 26021. 
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urbo C: The 
fastest, most 
efficient and easy- 
to-use C compiler at 
any price 


Compilation speed is more than 
7000 lines a minute, which makes 
anything less than Turbo C an 
exercise in slow motion. Expect 
what only Borland delivers: Quality, 
Speed, Power and Price. 


Turbo C: The C compiler 
for amateurs and 
professionals 

If you're just beginning and 
you've “kinda wanted to learn C,” 
now’s your chance to do it the easy 
way. Like Turbo Pascal, Turbo C’s 
got everything to get you going. 

If you're already programming 
in C, switching to Turbo C will 


Turbo C: a complete 
interactive development 
environment 


Like Turbo 
Pascal® and 
Turbo Prolog,’ 
““=—t Turbo C comes 
with an interactive editor that will 
show you syntax errors right in your 
source code. Developing, debug- 
ging, and running a Turbo C 
program Is a snap. 


Turbo C: The C compiler 
everybody’s been 
waiting for. Everybody 
but the competition 


Borland’s “Quality, Speed, Power 
and Price” commitment isn’t idle 
corporate chatter. The $99.95 price 
tag on Turbo C isn’t a “typo,” it’s 
real. So if you'd like to learn C in a 
hurry, pick up the phone. If you’re 


Technical Specifications 


[4 Compiler: One-pass compiler 


generating linkable object modules 
and inline assembler. Included is 
Borland’s high performance “Turbo 
Linker.” The object module is com- 
patible with the PC-DOS linker. Sup- 
ports tiny, small, compact, medium, 
large, and huge memory model 
libraries. Can mix models with near 
and far pointers. Includes floating 
point emulator (utilizes 8087/80287 
if installed). 


[4 Interactive Editor: The system 


includes a powerful, interactive full- 
screen text editor. If the compiler 
detects an error, the editor auto- 
matically positions the cursor 
appropriately in the source code. 


[4% Development Environment: A 


powerful “Make” is included so 
that managing Turbo C program 
development is highly efficient. 
Also includes pull-down menus 
and windows. 


[4 Links with relocatable object 


modules created using Borland’s 
Turbo Prolog into a single program. 


considerably increase your produc- 
tivity and help make your programs 
both smaller and faster. Actually, 
writing in Turbo C is a highly 
productive and effective method— 
and we speak from experience. 
Eureka: The Solver™ and our new 
generation of software have been 
developed using Turbo C. 


already using C, switch to Turbo C 


( [4 ANSI C compatible. 
and see the difference for yourself. 


[4 Start-up routine source code 
included. 


[4 Both command line and integrated 
environment versions included. 


System Requirements 


IBM PC, XT, AT, PS/2 or true compatibles. PC-DOS 
(MS-DOS) 2.0 or later. One floppy drive. 384K RAM. 


Turbo C, Turbo Prolog and Turbo Pascal are registered trademarks and 
MicroCalc, Turbo Linker and Eureka: The Solver are trademarks of Bor- 
land International, Inc. Microsoft C and MS-DOS are registered trade- 
marks of Microsoft Corp. IBM, XT, and AT are registered trademarks of 
International Business Machines Corp. 
International _BI-1104C 


Copyright 1987 Borland 


Sieve benchmark (25 iterations) 
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Benchmark run on a 6 Mhz IBM AT using Turbo C version 1.0 and the Turbo __ 
Linker version 1.0; Microsoft C version 4.0 and the MS overlay linker version 3.5 
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For the dealer nearest you or to order by phone call 


(800)255-8008 


in CA (800) 742-1133 in Canada (800) 237-1136 
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4585 SCOTTS VALLEY DRIVE 
SCOTTS VALLEY, CA 95066 
(408) 438-8400 TELEX: 172373 


